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Executive  Susunary 

Recent  trends  in  business,  medical,  aerospace,  and  military 
contexts  has  pushed  issues  associated  with  teams  and  teamwork  to 
the  forefront  of  the  social  science  research  agenda.  This  report 
describes  a  networked  software  program  called  TIDE^  and  shows  how 
this  program  can  be  used  in  scientific  studies  in  the  area  of  team 
decision  making.  This  report  lays  out  the  relationship  between 
TIDE^  and  the  existing  literature  on  groups,  and  then  describes  the 
theoretical  framework  associated  with  the  research  program  for 
which  TIDE^  was  developed.  The  paradigm  associated  with  this 
computer  program  and  the  program  of  research  for  which  it  was 
developed  involves  hierarchically  arranged  decision  making  teams 
where  expertise  is  differentially  distributed  among  various  team 
members.  At  the  core  of  this  paradigm  is  a  team-based  multiple  cue 
probability  learning  task  with  feedforward  instruction.  The 
initial  scenario  for  the  TIDE^,  involves  naval  Command  and  Control. 
This  scenario  is  described,  along  with  the  procedures  that  can  be 
used  to  manipulate  this  task  in  order  to  achieve  specific 
psychological  or  contextual  effects,  such  as  stress,  uncertainty, 
task  complexity  and  group  conflict.  The  report  also  describes  how 
this  initial  scenario  can  be  changed  from  naval  Command  and  Control 
to  virtually  any  other  type  of  decision  making  scenario  (e.g., 
investment  banking  or  personnel  selection) ,  so  long  as  the 
underlying  paradigm  remains  the  same.  It  also  describes  how  the 
program  can  be  manipulated  to  create  "single-person”  versions  of 
the  task,  in  order  to  facilitate  team  versus  individual 
comparisons.  TIDE^  not  only  provides  a  stimulus  material  for 
research  participants,  it  also  contains  sophisticated  sub-programs 
for  collecting,  sorting  and  storing  data.  These  sub-programs  are 
described,  along  with  the  procedures  one  can  execute  in  order  to 
accomplish  traditional  groups  or  decision  making  analyses  such  as 
sociograms,  communication  networks,  policy  capturing,  or  process 
tracing.  The  final  section  of  this  report  lays  out  the  hardware 
and  software  requirements  needed  to  run  TIDl^,  which  are  quite 
minimal  concerning  the  scope,  complexity  and  flexibility  of  the 
program. 
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Team  Interactive  Decision  Exercise  for  Teams  Incorporating 
Distributed  Expertise  (TIDE^) :  A  Program 
and  Paradigm  for  Team  Research 

Although  there  is  a  long  standing  interest  in  group  dynamics, 
recent  trends  in  business,  medical,  aerospace,  and  military 
contexts  have  pushed  group  oriented  issues  to  the  forefront  of  the 
social  science  research  agenda.  In  particular,  the  emergence  of 
work  teams  that  bring  together  people  with  differential  areas  of 
expertise  who  must  make  decisions  under  conditions  of  uncertainty 
and  time  pressure  are  of  increasing  interest  in  for  many  different 
kinds  of  social  organizations. 

For  example,  manufacturers  traditionally  separated  the  functions  of 
market  research,  product  design,  production  and  sales,  and  then  had 
these  differentiated  groups  performing  sequentially.  This  kind  of 
practice  is  less  suitable  to  meet  today's  competition.  In  order  to 
speed  the  product  development  cycle,  many  manufacturers  now  bring 
experts  in  these  four  divergent  areas  together  and  have  them  work 
together  in  teams.  In  the  medical  community,  the  complexity  of 
modern  medicine  has  created  a  large  number  of  medical  specialists 
who  often  have  to  work  together  in  teams  to  manage  the  health  care 
of  a  single  patient.  In  the  aerospace  industry,  the  functioning 
of  aircrews  under  conditions  of  stress  has  also  emerged  as  a 
critical  problem.  In  several  cases,  large  scale  human  tragedies 
like  the  Tenifere  accident  have  been  traced  to  communication 
breakdowns  among  pilots,  co-pilots,  navigators,  air  controllers  and 
ground  controllers  (Foushee,  1987) . 

Finally,  in  the  military  context,  events  like  those  of  the  U.S.S. 
Stark  and  U.S.S.  Vincennes  have  highlighted  the  importance  of  group 
process  issues  and  the  difficulty  of  addressing  these  through 
policy  changes  alone.  In  the  U.S.S.  Stark  incident,  air  patrol 
teams  that  included  the  frigate  itself,  AWACs  reconnaissance  planes 
and  land  based  radar  units  allowed  an  approaching  Iraqi  jet  to 
position  itself  and  then  launch  an  attack  that  led  to  the  death  of 
37  servicemen.  Policy  changes  in  the  wake  of  this  incident 
loosened  the  "rules  of  engagement"  for  American  vessels  operating 
in  the  gulf.  These  measures  then  backfired  thirteen  months  later 
when  air  patrol  teams  working  on  and  around  the  Aegis  Cruiser 
U.S.S.  Vincennes  mistakenly  shot  down  an  Iranian  Airbus  killing 
over  150  innocent  civilians.  Thus,  the  need  for  research 
addressing  issues  associated  with  teams  of  experts  making  decisions 
under  time  pressure  in  uncertain  situations  has  never  been  greater. 
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Traditional  Studies  of  Groups  and  the  Need  for  TIDE^ 

Groups  have  been  defined  as  configurations  of  more  than  two 
interdependent  individuals  who  interact  over  time  (McGrath,  1984) . 
Teams  are  special  cases  of  groups  where,  in  addition  to  meeting  all 
the  definitional  rules  of  groups,  teams  are  also  performing  some 
task  where  success  or  failure  has  important  consequences  for  all 
team  members  (Ilgen,  Major,  Hollenbeck,  and  Sego,  1991a) .  Ilgen, 
et  al.  have  argued  that  the  existing  group  literature  is  limited  in 
its  ability  to  answer  questions  about  the  kinds  of  teams  that  we 
have  just  described.  Little  existing  research  focuses  on  decision 
making  accuracy.  Much  of  it  fails  to  pay  sufficient  attention  to 
issues  of  external  validity  along  the  dimensions  which  are  critical 
to  ongoing  teams. 

In  many  cases,  this  latter  step  is  not  at  issue  because  the  groups 
being  studied  are  not  pursuing  any  specific,  objectively  verifiable 
goal,  where  there  are  clear  right  and  wrong  decisions. 

Moreover,  many  real-world  work  teams,  unlike  their  laboratory 
counterparts,  are  comprised  of  members  with  heterogeneous  skills 
and  differentiated  expertise.  Research  that  focuses  on  individuals 
with  homogeneous  skills  and  expertise  cannot  deal  with  the  source 
from  which  many  of  the  problems  confronting  current  work  teams 
emerge . 

Finally,  one  last  feature  of  current  work  teams  that  is  not  well 
addressed  by  the  current  groups  literature  is  the  distributed 
nature  of  team  members.  Most  group  research  deals  with  face-to- 
face  interactions.  Members  of  many  current  work  teams,  however, 
are  often  physically  separated  and  communicate  through 
technologically  mediated  methods  (fax,  electronic  mail,  conference 
calls,  etc.)  which  greatly  complicates  and  changes  the  nature  of 
team  processes.  The  degree  to  which  research  on  face-to-face 
interactions  that  are  rich  in  information  redundancy,  verbal  and 
non-verbal  feedback  will  generalize  to  more  confined  technological 
media  is  an  open  question. 

In  this  report  we  describe  a  simulation  called  TIDE^.  TIDE^  is  a 
series  of  computer  programs  that  constitute  a  vehicle  for 
conducting  team  research.  TIDE^  stands  for  Team  Interactive 
Decision  Exercise  for  Teams  Incorporating  Distributed  Expertise. 
It  was  developed  to  provide  a  paradigm  for  studying  team  decision 
making  in  the  kinds  of  contexts  that  confront  many  existing  and 
developing  work  teams.  These  contexts  can  be  characterized  as 
complex,  uncertain,  ambiguous,  and  fast  tempo.  In  addition, 
confronting  problems  in  these  contexts  requires  differentiated 
expertise  embodied  in  persons  who  are  often  geographically 
distributed  and  working  under  tight  time  pressures  where  decision 
quality  is  important. 

Despite  being  targeted  for  these  kinds  of  contexts,  however,  TIDE^ 
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is  a  flexible  system  that  is  adaptable  to  many  different  kinds  of 
decision  making  contexts  —  including  non-group  research  where  the 
focus  is  on  a  single  decision-maker.  As  a  set,  the  programs  (a) 
provide  a  standardized  decision  making  stimulus  for  people  who 
communicate  with  each  other  over  dedicated  lines,  (b)  support 
programs  for  manipulating  cues  associated  with  decision 
alternatives,  (c)  support  programs  for  radically  changing  the 
decision  making  context  confronting  participants,  (d)  support 
programs  for  sorting,  summarizing,  and  analyzing  quantitative  data 
generated  by  teams  working  on  the  task,  and  (e)  support  programs 
for  aiding  the  content  analysis  of  qualitative  data  generated  by 
teams  working  on  the  task. 

The  purpose  of  this  report  is  to  familiarize  the  reader  with  TIDE^. 
The  report  is  laid  out  in  eight  sections.  This  section  discusses 
the  rationale  for  the  development  of  TIDE^.  The  next  section 
presents  an  overview  of  the  theoretical  background  for  the  research 
program  for  which  TIDE^  was  specifically  developed.  Although 
researchers  interested  in  these  kinds  of  constructs  and 
relationships  will  find  TIDE^  particularly  useful,  the  flexible 
nature  of  the  program  makes  it  suitable  for  many  programs  of 
research  that  are  only  tangentially  interested  in  the  constructs 
discussed  here. 

The  third  section  describes  the  initial  version  of  TIDE^  that 
accompanies  this  document  and  describes  the  naval  Command  and 
Control  (C^)  scenario.  This  section  describes  the  task  from  the 
participants'  point  of  view  as  well  as  the  experimenter's  point  of 
view.  As  such,  it  describes  how  to  manipulate  and  measure  a  number 
of  constructs  commonly  of  interest  to  decision  making  researchers 
or  researchers  working  with  teams. 

The  fourth  section  of  this  report  discusses  how  to  radically  change 
the  scenario  or  frame  placed  around  the  paradigm  in  order  to  create 
a  context  more  suitable  for  other  types  of  research.  For  example, 
one  can  move  from  a  naval  command  and  control  scenario  to  an 
investment  banking  scenario,  or  a  scenario  involving  a  personnel 
selection  decision,  or  a  scenario  involving  the  prediction  of  real 
world  events  (e.g.,  horse  races,  stock  prices,  jury  decisions, 
etc) .  This  section  also  explores  non-research  uses  of  TIDE^  such 
as  team  and  individual  assessment,  training  and  development.  The 
fifth  section  discusses  two  ways  of  transforming  TIDE^  into  an 
individual  exercise. 

Section  six  discusses  the  output  that  is  generated  when 
participants  work  on  TIDE^.  This  section  details  the  quantitative 
and  qualitative  data  that  are  automatically  recorded.  It  also 
documents  how  files  are  generated  that  summarize,  sort  and  prepare 
these  data  for  analysis  with  SPSS,  SAS  or  other  data  analytic 
software. 
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Section  seven  shows  how  to  analyze  the  data  collected  and  arrayed 
by  TIDE^  to  conduct  common  types  of  team  or  decision  making 
analyses.  These  include  (a)  policy  capturing  of  individual 
judgments  from  raw  data,  (b)  policy  capturing  team  decisions  from 
raw  data  or  summary  judgments  of  individual  team  members,  (c) 
process  tracing  the  timing  and  sequence  of  information  search,  (d) 
priming  and  recency  analyses  focusing  on  the  effects  of  timing  and 
sequence  on  decisions,  and  (e)  sociometric  analyses  focusing  on  who 
communicates  with  whom,  when,  how  and  about  what.  Finally,  the 
section,  presents  hardware  and  software  requirements  associated 
wich  using  TIDE^. 
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Theoretical  Background  and  Conceptual  Framework 

The  theory  and  conceptual  framework  that  underlie  the  program  of 
research  for  which  TIDE^  was  developed  have  been  described  in 
detail  by  Ilgen,  Major,  Hollenbeck,  and  Sego  (1991b).  Exhibits  la 
through  Ic  will  be  used  to  briefly  explain  the  theory  and 
conceptual  framework. 

Exhibit  la  illustrates  a  hierarchical  decision  making  team  with 
four  members.  Such  teams  have  three  primary  characteristics.  The 
first  of  these  is  that  of  hierarchy;  team  members  are  not  all  of 
equal  status.  In  the  illustration,  member  D  is  of  higher  status 
with  the  other  three  members  reporting  to  him  or  her.  As  drawn, 
the  other  three  members  do  not  differ  in  formal  status.  The  second 
feature  is  that  the  primary  task  of  the  team  is  to  make  decisions. 
In  the  case  illustrated,  each  of  the  subordinate  members  reaches  a 
decision  or  judgment  (d^-d^) ,  and  the  subordinate's  recommendation 
is  passed  to  the  leader  who  also  makes  a  decision  (d^) .  Typically, 
and  as  is  the  case  in  Exhibit  la,  the  leader's  decision  represents 
the  decision  of  the  team. 
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Exhibit  lb  builds  upon  the  hierarchy  of  Exhibit  la  by  introducing 
distributed  expertise.  According  to  the  model  of  Ilgen,  et  al. 
(1991b)  ,  the  distribution  of  expertise  in  a  team  is  represented  by 
the  allocation  of  critical  information  regarding  the  decision  to 
individuals  in  the  team.  The  pattern  of  distribution  represents 
the  expertise  system.  On  the  far  left  of  Exhibit  lb  is  a  column  of 
Xs  representing  dimensions  of  information.  If,  for  example,  the 
team  were  responsible  for  purchasing  a  new  robot  for  a 
manufacturing  unit,  the  Xs  would  represent  such  characteristics  as 
price,  system  reliability,  vender  service  capability,  and  capacity. 
Each  X  is  a  vector  of  elements  where  the  elements  represent 
specific  values  on  the  dimension  for  each  of  the  decisions. 
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Using  the  robot  purchase  as  an  example  and  assuming  that  price  is 
represented  by  X,,  the  price  of  a  particular  robot  would  be  the 
entry  on  the  vector  for  that  robot.  Expertise  is  represented  in 
the  exhibit  by  the  association  of  information  with  individuals. 
Individuals'  areas  of  expertise  are  construed  to  be  described  by 
the  pieces  of  information  to  which  each  person  has  access.  In 
Exhibit  lb.  Person  A  is  an  expert  in  the  knowledge  domain 
represented  by  X,  and  X,,  Person  B  by  Xg,  X,,  and  X^,  Person  C  by  Xj 
and  X^,  and  the  leader  by  X^  and  X^.  Note  that  it  is  r  ^t  necessary 
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for  information  to  be  the  unique  property  of  one  person.  In  the 
exhibit,  information  on  Dimension  2  is  available  to  both  Persons  A 
and  B,  and  the  leader  has  direct  knowledge  about  both  1  and  6  even 
though  those  dimensions  are  known  by  Persons  A  and  C,  respectively. 
Thus,  although  the  distribution  of  expertise  is  represented  by  the 
way  in  which  information  is  allocated  to  every  member  of  the  group, 
it  is  not  necessary  that  all  of  the  information  be  available  to 
only  one  of  the  team  members.  On  the  other  hand,  it  is  also  not 
acceptable  to  have  all  members  of  the  team  have  direct  access  to 
all  of  the  relevant  information  if  the  expertise  in  the  group  is  to 
be  distributed.  In  other  words,  when  everyone  knows  all 
information  without  getting  some  of  it  from  other  team  members,  the 
level  and  nature  of  expertise  in  that  group  is  not  considered  to  be 
distributed  within  the  group  as  a  matter  of  definition. 

Exhibit  lb  introduces  one  other  important  feature  of  teams  —  a 
conanunication  structure.  By  definition,  communication  structures 
exist  among  persons.  The  one  illustrated  in  the  exhibit  shows 
Person  A  being  able  to  communicate  directly  only  with  the  leader. 
Person  D.  Persons  B  and  C  can  communicate  directly  with  the  leader 
and  with  each  other.  Finally,  the  leader  communicates  directly 
with  each  of  the  subordinates  A,  B,  and  C.  In  this  team,  it  is 
still  possible  for  all  persons  on  the  team  to  communicate  with  all 
others,  but,  for  Person  A,  the  communication  with  Persons  B  and  c 
is  indirect.  That  is,  A  must  go  through  D  to  get  messages  to  and 
from  the  other  two  subordinates.  The  same  is  true  for  B  and  C. 

The  combination  of  the  communication  system  with  the  expertise 
system  provides  the  structure  within  a  team  for  potential  access  to 
information  by  each  team  member.  Take,  for  example.  Person  B  in 
Exhibit  lb.  This  person  may  access  information  on  Xj,  Xj  and  X^ 
directly.  The  person  is  one  step  removed  from  information  on  Xj 
and  X^;  he  or  she  can  ask  Person  C  for  that  information,  assuming 
that  Person  C  honors  Person  B's  request,  and,  for  X^,  the  same 
could  be  done  through  the  leader.  Finally,  Person  B  can  access 
information  on  X,  indirectly  by  going  through  two  persons,  first 
the  leader  who  could  then  go  through  Person  A  to  get  the 
information  and  relay  it  back  to  B.  A  similar  two  step  indirect 
path  exists  from  B  through  the  leader  and  Person  C  to  information 
on  Xj.  In  most  cases,  however,  it  would  appear  to  be  more 
efficient  to  get  that  information  by  going  directly  to  Person  C. 

With  Exhibit  lb,  we  have  incorporated  distributed  expertise  into  a 
team  hierarchy  in  such  a  wa>  as  to  provide  a  structure  for 
describing  how  information  becomes  available  to  team  members  for 
making  decisions.  The  availability  of  information  relevant  to  a 
team  decision  represents  a  necessary  but  not  sufficient  condition 
for  reaching  a  decision.  The  remainder  of  the  process  involves  the 
decision  itself.  In  particular,  the  concern  is  with  how  the 
information  is  used  by  the  team  to  reach  a  decision  and  with  the 
quality  of  the  decision.  In  order  to  evaluate  the  latter,  decision 
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making  research  typically  has  used  decisions  for  which  the  quality 
of  decisions  can  be  evaluated  against  criteria  established  a 


The  model  of  Ilgen  et  al  (1991b)  is  an  adaptation  of  the  Brunswick 
Lens  model  frequently  used  to  model  decisions  of  individuals  (see 
Stevenson,  Busmeyer  and  Naylor  (1991)  for  an  excellent  description 
of  the  model  and  its  use  for  individual  decisions.)*  At  the 
individual  level,  a  problem  is  defined  in  terms  of  a  finite  set  of 
dimensions  of  information  for  which  the  decision  to  be  reached  can 
be  described  as  a  function  of  the  cues,  and  the  function  can  be 
established  a  priori.  In  this  way,  the  functional  relationship  of 
the  cues  to  the  decision  becomes  the  standard  to  which  the  actual 
decision  made  by  t^e  decision  maker  can  be  compared. 

Exhibit  Ic  introduces  the  decision  process  to  the  combination  of 
the  hierarchy  of  Exhibit  la  and  the  expertise  and  communication 
systems  of  Exhibit  lb.  As  was  the  case  in  the  first  two  exhibits, 
six  dimensions  of  information  are  used  to  reach  a  decision  (X^  -  X^) . 
Working  left  from  the  X,s,  the  a  priori  or  "correct"  decision  is 
represented  by  .  The  lines  between  the  dimensions  of  information 
and  the  decision  represent  the  extent  to  which  each  one  of  the 
dimensions  is  related  (contributes)  to  the  decision.  In  the 
individual  decision  making  literature  using  the  Brunswick  Lens 
model,  a  linear  regression  model  is  used  to  relate  dimensions  to 
decisions.  Regression  weights  are  chosen  a  priori,  and  then  sets 
of  cues  and  decisions  are  generated  to  match  the  chosen  model.  The 
team  construal  of  the  decision  model  represented  in  Exhibit  Ic  is 
exactly  analogous  to  this.  Here,  a  set  of  cue  values  are  generated 
along  with  a  set  of  decisions  in  order  to  fit  an  a  priori  model, 
and  the  model  generated  from  the  sample  of  cues  presented  to  the 
group  is  represented  in  the  left  hand  portion  of  Exhibit  Ic.  The 
Yjj,  is  the  "correct"  decision  to  which  the  team's  decision  can  be 
compared. 


Insert  Exhibit  Ic 


The  right  hand  portion  of  Exhibit  Ic  represents  decisions  made  in 
the  team.  As  illustrated,  there  are  two  sets  of  decisions.  The 
first  of  these  includes  the  decisions  made  by  Persons  A,  B  and  C, 
symbolized  by  Y^j^,  Y^*  and  Y^j^..  The  exhibit  illustrates  the  case 
where  all  six  sets  of  information  are  used  by  each  team  member  to 
make  a  decision.  Each  team  member's  decision  can  be  represented  or 
captured  by  regressing  the  individual's  decisions  on  the  cues 
presented  to  him  or  her.  The  second  decision  is  that  of  the 
leader.  This  decision  has  the  potential  for  being  a  little  more 
involved  than  the  subordinate  decisions  in  a  group  structured  in 
the  hierarchical  fashion  illustrated.  One  way  for  the  leader  to 
make  a  decision  is  exactly  the  same  as  that  of  the  subordinates. 
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That  is  to  say,  the  leader  can  base  his  or  her  decision  upon  a 
linear  combination  of  the  six  cues.  However,  unlike  the 
siibordinates ,  in  the  configuration  illustrated  in  Exhibit  Ic  the 
leader  has  access  to  the  decisions  of  each  of  the  subordinates. 
Thus,  the  subordinate  decisions  are  analogous  to  cue  dimensions  for 
a  decision  by  the  leader  based  on  three  cues.  Therefore,  the 
leader's  decision  can  be  modeled  as  a  function  of  the  three 
svibordinates '  decisions  by  regressing  onto  the  leader's  decision, 
the  subordinates'  decisions.  Within  this  framework,  one  way  to 
evaluate  the  accuracy  of  either  the  leader's/team's  decision  and/or 
those  of  the  team  members  is  to  compare  them  to  the  decisions 
judged  a  priori  to  be  most  appropriate,  specifically,  to  compare 

or  Y«i)  to  Y^.. 

The  three  exhibits  just  described  complete  the  conceptual  framework 
to  be  used  here  regarding  decision  making  in  hierarchical  teams 
with  distributed  expertise.  Onto  this  framev'ork  can  be  mapped  a 
large  nvunber  of  team  and  individual  constructs  that  are  likely  to 
play  a  major  role  in  team  decision  making.  At  the  individual 
level,  for  example,  it  can  be  argued  that  team  members'  abilities 
will  affect  the  decisions  of  both  the  persons  and  the  team.  At  the 
team  level  constructs  such  as  conflict,  coordination,  cooperation 
and  climate  have  been  shown  to  be  important.  The  research  on  teams 
from  the  perspective  developed  here  will  incorporate  these  and 
other  individual  and  team  constructs  to  study  team  decision  making 
when  the  decision  making  task  is  modeled  by  the  structures 
introduced  in  Exhibits  la,  lb,  and  Ic. 
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Initial  Scenario,  Task  and  Targets 

The  initial  scenario  associated  with  TIDE^  is  that  of  a  four-person 
naval  Command  and  Control  team  assigned  the  task  of  monitoring  the 
airspace  in  the  vicinity  of  an  aircraft  carrier  battle  group. 
Exhibit  2  shows  a  one  page  description  of  the  scenario  provided  to 
participants  that  introduces  them  to  the  team's  mission.  Exhibit 
3  shows  an  overview  description  of  the  roles  assigned  to  the  four 
players  as  well  as  the  types  of  judgments  they  need  to  make. 


Insert  Exhibits  2  and  3  here 


Information  Available  and  Threat  Determination 

The  team  can  measure  each  incoming  target  on  nine  attributes.  The 
names  and  descriptions  of  all  the  attributes  are  shown  in  Exhibit 
4 .  This  exhibit  also  shows  the  scale  associated  with  each 
characteristic  as  well  as  its  possible  range.  The  degree  of  threat 
represented  by  the  target  can  be  ascertained  by  knowing  (a)  the 
target's  standing  on  these  nine  attributes  and  (b)  the  five  rules 
that  describe  how  target  characteristics  combine  to  determine  the 
level  of  threat.  The  five  rules  associated  with  the  initial 
scenario  are  shown  in  Exhibit  5.  The  last  four  rules  are  called 
"combination  rules"  because  the  degree  of  threat  associated  with 
knowledge  of  one  attribute  can  only  truly  be  ascertained  if  one 
also  has  knowledge  of  the  attribute  with  which  it  combines. 


Insert  Exhibit  4  and  5  here 


Mathematical  Structure  Underlying  the  Task 

At  the  core  of  this  simulation  is  a  mathematic  linear  combination 
of  the  form  shown  below  in  Equation  1,  where  W  is  a  cue  weight  and 
B  is  a  cue  value. 

[1]  True  Score  =  W,  B,  +  Wj  83  +  Wj  Bj  +  B^  +  Wj  Bj 

The  resulting  value  attained  by  assigning  weights  and  inserting  cue 
values  into  this  linear  combination  determines  the  "true  score"  for 
each  target.  Each  "rule"  that  was  described  to  participants  in  the 
instructions  coincides  with  one  term  in  the  equation  that  gives  the 
true  score  for  each  target. 

The  linear  combination  associated  with  the  initial  version  of  TIDE^ 
therefore  has  five  components,  four  of  which  are  combinations  of 
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multiple  cues  to  match  the  four  combination  rules.  The  exact 
linear  combination  used  in  the  initial  version  of  TIDE^  is  shown  in 
Equation  2  below,  where  the  parenthetic  value  is  the  cue  weight, 
and  the  #  indicates  the  number  of  the  attribute  described 
previously  in  Exhibit  4  (i.e.,  #1  is  speed,  #2  is  altitude,  #9  is 
range,  etc.) 

[2]  TS  =  (2)(#5)  +  (l)(#l)(#6)  +  (l)(#2)(#7)  +  (l)(#3)(#8)  +  (l)(#4)(#9) 

The  cues  can  take  on  values  of  0  (i.e.,  non  threatening),  1  (i.e., 
somewhat  threatening)  or  2  (i.e.,  very  threatening).  So  for 
example,  the  first  rule  deals  with  the  attribute  IFF  (i.e.,  #5). 
This  attribute,  from  Equation  2  has  a  weight  of  2.  Thus,  if  the 
cue  value  takes  on  a  value  of  zero,  this  component  of  the  overall 
linear  combination  becomes  zero.  If  the  cue  takes  on  a  value  of 
one,  this  component  of  the  linear  combination  takes  on  a  value  of 
two.  If  this  cue  takes  on  a  value  of  two,  this  component  of  the 
linear  combination  takes  on  a  value  of  four. 

As  an  additional  example,  the  second  rule  is  a  combination  rule 
involving  Speed  and  Direction  (i.e..  Cues  #l  and  #6)  where  the 
combination  of  these  two  cues  is  weighted  1.  Thus,  if  both  cues 
take  on  a  value  of  two,  then  this  component  of  the  linear 
combination  takes  on  a  value  of  four.  If  they  both  took  on  a  value 
of  one,  this  component  of  the  overall  linear  combination  is  one. 
If  either  one  of  the  cues  took  on  a  value  of  zero,  this  component 
of  the  linear  combination  would  become  zero,  regardless  of  the 
value  associated  with  the  other  cue  (i.e.,  since  one  of  the 
components  becomes  zero,  the  product  of  all  three  components 
becomes  zero) . 

Exhibit  6  shows  how  raw  data  on  each  of  the  nine  cues  translates 
into  "non-threatening,"  "somewhat  threatening"  and  "very 
threatening"  cue  values. 


Insert  Exhibit  6  here 


Thus,  in  the  initial  version  of  TIDE^'  the  true  score  for  each 
target  ranges  from  0  (i.e.,  a  completely  non-threatening  target 
where  all  cue  values  equal  0)  to  20  (i.e.,  a  very  threatening 
target  where  all  cue  values  equal  2).  Verbally,  a  very  threatening 
target  would  appear  similar  to  the  target  described  in  the  first 
paragraph  in  the  section  "How  Rules  Combine..."  back  in  Exhibit  5. 
Verbally,  a  completely  non-threatening  target  would  appear  similar 
to  the  target  described  in  the  second  paragraph  of  that  section. 

Intermediate  values  between  0  and  20  call  for  decisions  that  are 
more  aggressive  than  IGNORE  and  less  aggressive  than  DEFEND. 
Exhibit  6  shows  how  true  scores  on  targets  are  translated  into  the 
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"Correct  Decisions"  that  serve  as  the  criterion  against  which  teeun 
decisions  are  evaluated.  The  target  described  in  the  third 
paragraph  of  the  section  on  "How  Rules  CoiDbine"  in  Exhibit  5  has  a 
true  score  of  10.  This  score  comes  about  as  shown  in  Equation  3 
below. 

[3]  TS  =  (2)  (2)  +  (1)(0)(0)  +  (1)(2)(2)  +  (1)  (0)  (0)  +  (1)  (1)  (2) 

10  =4  +  0  +  4  +  0  +  2 


For  researchers  familiar  with  Multiple  Cue  Probability  Learning 
(MCPL)  tasks,  the  core  of  this  simulation  can  be  construed  as  an 
MCPL  task  with  feedforward  (Hammond  and  Summers,  1972) . 
Feedforward  simply  refers  to  the  fact  that  participants  perform  the 
task  after  being  instructed  in  the  weights  assigned  to  cues. 


Areas  of  Expertise 

One  feature  of  TIDE^  that  makes  it  unique  relative  to  other  MCPL 
tasks  is  that  the  task  is  performed  in  a  team  context  where 
individual  members  have  different  areas  of  expertise.  In  the  naval 
Command  and  Control  scenario,  the  participant  playing  the  role  of 
the  Commanding  Officer  (CO)  of  the  Carrier  is  the  team  leader  and 
the  person  who  ultimately  decides  what  stance  should  be  taken 
toward  each  target.  Each  of  the  other  team  members  makes 
recommendations  to  the  leader. 

Each  team  member  has  expertise  that  is  unique  to  his  or  her  role. 
That  expertise  comes  in  three  forms,  (a)  the  ability  to  measure 
attributes  of  the  target,  (b)  the  ability  to  translate  raw  data  on 
target  attributes  into  judgments  regarding  how  threatening  the 
target  is  on  that  attribute  and  (c)  the  knowledge  of  rules. 

For  example,  although  all  team  members  know  that  military  aircraft 
are  more  threatening  than  non-military  aircraft,  only  two  people  in 
the  team  can  actually  measure  IFF  (i.e..  Attribute  #5).  These  two 
team  members  are  the  only  ones  trained  in  how  to  translate  raw  data 
on  IFF  (i.e.,  0.0  to  1.6  Mhz)  into  judgments  about  threat  (i.e., 
non-threatening,  somewhat  threatening  or  very  threatening) . 

Also,  each  team  member  has  to  memorize  one  of  the  four  combination 
rules  (e.g.,  one  member  must  memorize  how  speed  and  direction  go 
together) .  Thus,  at  least  one  member  of  every  team  will  be  an 
expert  on  one  of  the  combination  rules. 

Like  all  the  other  team  members,  the  CO  of  the  Carrier  memorizes 
one  combination  rule.  Relative  to  his  or  her  teammates,  however, 
the  Carrier  can  only  measure  a  relatively  small  number  of  target 
attributes.  The  distinctive  competency  of  the  Carrier  is  that  this 
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person  is  an  expert  in  terms  of  knowing  the  expertise  of  all  the 
other  team  members. 

Exhibit  7  shows  the  specific  role  instructions  provided  to  the 
Carrier  position.  Exhibits  8,  9  and  10  show  the  corresponding 
specific  instructions  given  to  participants  occupying  the  Coastal 
Air  Defense  (CAD) ,  AWACs,  and  Cruiser  positions. 


Insert  Exhibits  7,  8,  9  and  10  here 


Patrol  Sessions  and  the  Mechanics  of  Making  Decisions 

Patrol  sessions  refer  to  the  time  that  teams  are  responsible  for 
monitoring  air  traffic  in  their  designated  area.  While  teams  are 
monitoring  traffic,  they  are  stationed  at  a  computer  monitor  that 
displays  the  screen  shown  in  Exhibit  11.  This  screen,  referred  to 
as  the  "sea  screen,"  has  four  icons  on  it,  to  remind  team  members 
that  there  are  four  members  of  the  team;  the  Carrier  (i.e.,  the 
team  leader),  the  AWACS  (i.e.,  plane),  the  Coastal  Air  Defense  unit 
(i.e.,  the  land  mass)  and  the  Aegis  Cruiser  (i.e.,  the  ship).  A 
red  asterisk  in  the  middle  of  the  screen  indicates  the  presence  of 
a  target  in  the  teams  airspace.  A  countdown  clock  on  the  screen 
tells  how  long  before  the  team  must  render  a  decision.  The  target 
will  begin  to  beep  when  there  is  30  seconds  remaining.  The 
frequency  of  the  beeping  will  increase  as  time  winds  down.  This 
gives  a  clear  impression  that  the  time  available  for  making  a 
decision  is  running  out.  In  order  to  give  the  carrier  time  to 
review  the  judgments  of  the  other  team  members,  the  outlying 
stations  should  begin  rendering  their  judgments  at  this  time.  If 
the  Carrier  position  (i.e.,  the  leader)  fails  to  register  the 
team's  decision  with  respect  to  the  target  in  the  prescribed  time, 
this  is  treated  as  if  the  team  decided  to  IGNORE  the  target.  This 
could  result  in  a  positive  outcome  if  the  team  should  have  ignored 
the  target,  but  could  lead  to  a  disaster  if  the  target  called  for 
a  more  aggressive  response. 


Inset  Exhibit  11  here 


The  bar  at  the  top  of  the  screen  indicates  what  the  team  can  do 
while  on  patrol.  There  are  basically  five  things  that  teams  can  do 
when  trying  to  decide  what  to  do  with  a  target. 

The  Measure  Function.  If  a  team  member  hits  the  ALT  key,  the 
menu  will  highlight  Measure.  This  option  allows  each  participant 
to  take  measurements  of  the  target  on  attributes  that  he  or  she  can 
measure.  The  option  is  chosen  by  hitting  RETURN  (or  hitting  the 
down  arrow  key)  when  Measure  is  highlighted.  If  they  choose  this 
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option,  they  will  get  a  menu  listing  the  attributes  they  can 
measure.  They  then  use  the  arrow  keys  to  move  to  the  attribute 
they  wish  to  measure.  When  the  appropriate  attribute  is 
highlighted,  they  hit  RETURN.  They  can  also  measure  the  desired 
attribute  by  simply  typing  the  letter  indicated  in  red  on  the  menu 
(we  will  refer  to  these  throughout  as  "hot  keys") .  For  example,  if 
they  just  type  "s",  they  will  learn  the  "Speed"  of  the  target.  The 
value  of  the  target  on  the  attribute  selected  will  appear  at  the 
bottom  left  portion  of  the  screen.  Hitting  RETURN  again  will 
remove  this  information  from  the  screen.  If  participants  do  not 
hit  return,  this  information  will  go  away  on  its  own  after  5 
seconds. 

The  Measure  menu  also  has  two  entries  called  "Sximmary"  and  "Log." 
If  they  highlight  "Summary"  and  then  hit  RETURN,  a  summary  of 
everything  they  know  about  this  specific  target  will  appear  on  the 
screen  (this  includes  what  was  measured  and  what  has  been  received 
from  others  via  transmissions) .  Participants  can  also  get  this 
summary  by  just  hitting  the  F2  function  key.  If  they  highlight 
"Log"  and  then  hit  return,  they  will  get  a  summary  of  all  text 
messages  that  have  ever  been  sent  to  them  and  recorded  into  their 
"Log."  The  purpose  of  the  "Log"  will  become  clearer  after  we 
discuss  the  "Receive"  option. 

The  Query  Function.  If  the  participant  hits  the  ALT  key  and 
then  hits  "Q,"  Query  will  be  highlighted.  Query  allows  team 
members  to  ask  other  players  for  information  on  the  target.  If  the 
participant  hits  RETURN  (or  presses  the  down  arrow  key)  while  Query 
is  highlighted,  another  menu  will  be  called  up  that  presents  all 
nine  attributes.  Participants  can  use  the  arrow  keys  to  move  up  or 
down  to  the  attribute  on  which  they  would  like  information  and  then 
hit  RETURN  (here  too  participants  could  also  simply  use  the  hot 
keys) .  This  will  lead  to  another  menu  at  the  bottom  right  portion 
of  the  screen  that  asks  from  whom  the  participant  wants  to  get  this 
information.  Again,  participants  can  use  the  arrow  keys  to 
highlight  who  they  want  to  ask.  The  highlighted  position  will  have 
white  brackets  surrounding  the  name.  When  the  right  person  is 
highlighted,  they  hit  RETURN.  Another  box  will  appear  telling  them 
that  the  query  was  sent.  If  they  hit  RETURN  again,  this  message 
will  disappear. 

The  Transmit  Function.  If  participants  press  the  ALT  key  and 
then  hit  "T,"  Transmit  will  be  highlighted.  Transmit  allows  a  team 
member  to  send  information  to  other  team  members.  If  RETURN  (or 
the  down  arrow  key)  is  hit  while  Transmit  is  highlighted,  another 
menu  will  be  called  up  that  asks  them  what  they  want  to  send.  Team 
members  can  send  two  kinds  of  information.  First,  they  can  send 
data  on  any  attribute  that  they  have  measured.  To  do  this,  they 
can  simply  use  the  arrow  keys  to  move  up  or  down  to  the  attribute 
they  want  to  send,  and  then  hit  RETURN  (again  they  could  also 
simply  use  the  hot  keys) .  This  will  lead  to  another  menu  at  the 
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bottom  right  portion  of  the  screen  that  asks  them  where  they  want 
to  send  this  information.  Using  the  arrow  keys,  they  highlight  to 
whom  they  want  to  send  the  information  as  indicated  by  white 
brackets  surrounding  the  position  name.  When  the  correct  position 
is  highlighted,  they  hit  RETURN.  Another  box  then  appears  telling 
them  that  the  transmission  was  sent.  If  they  hit  RETURN  again, 
this  message  will  disappear. 

It  is  important  to  stress  that  in  order  to  Transmit  data  on  an 
attribute,  the  participants  must  have  measured  the  attribute  first. 

The  Transmit  menu  includes  a  selection  called  "Text.”  Choosing  this 
option  allows  the  participant  to  send  a  text  message  to  another 
player  or  to  themselves.  If  they  hit  RETURN  when  the  "Text"  box  is 
highlighted,  they  will  get  another  menu  asking  them  where  they  want 
to  send  this  text  message.  They  can  use  the  arrow  keys  to 
highlight  where  they  want  to  send  the  message  and  then  hit  RETURN. 
They  will  then  be  presented  with  a  long  thin  rectangular  box,  into 
which  they  can  type  their  message.  Messages  can  only  be  60 
characters  long.  After  participants  have  typed  their  message,  they 
should  hit  return,  which  ends  and  sends  the  text  transmission.  An 
indicator  will  appear  telling  them  that  the  transmission  was  sent. 
Hitting  RETURN  again  removes  this  message. 

Participants  can  also  send  text  messages  to  themselves  using  these 
same  procedures.  This  creates  a  running  log  of  personal  notes  that 
can  be  reviewed  at  any  time  during  the  experimental  sessions. 
Messages  send  to  oneself  are  automatically  received  and  saved. 

The  Receive  Function.  If  participants  press  the  ALT  key  and 
then  hit  "R"  the  menu  will  highlight  Receive.  This  option  allows 
the  receipt  of  messages  from  other  team  members.  Three  kinds  of 
messages  can  be  received.  First,  other  team  members  may  have  a 
question  about  data  associated  with  the  target.  As  we  have  seen 
already,  this  is  called  a  "Query."  Second  the  team  members  may  wish 
to  tell  the  participant  something.  Team  members  can  tell  each 
other  things  in  two  ways.  First,  they  may  want  to  give  each  other 
raw  data  on  the  target,  which  we  saw  earlier  was  called  a 
"Transmission."  Second,  they  may  wish  to  send  a  text  message, 
which  we  referred  to  as  a  "Message." 

Participants  are  made  aware  of  the  fact  that  they  have  something  to 
Receive  from  others  by  indicators  that  appear  at  the  bottom  left 
portion  of  the  screen.  If  they  see  a  "Qry"  this  means  someone  is 
asking  for  information.  If  they  see  a  "Trn"  it  means  someone  is 
sending  them  a  transmission.  If  they  see  a  "Msg"  someone  is 
sending  them  a  text  message.  Hitting  Receive  when  none  of  these 
indicators  are  off  accomplishes  nothing,  since  when  they  are  all 
off,  there  is  nothing  to  receive. 

When  there  is  something  to  receive,  hitting  Receive  will  call  up 
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another  menu  that  will  show  what  there  is  to  receive  and  from  whom 
it  came.  Participants  can  use  the  up  and  down  arrow  keys  to 
highlight  what  message  they  would  like  to  Receive.  When  the 
desired  communication  is  highlighted,  they  just  hit  RETURN  and  the 
query,  transmission  or  message  highlighted  will  appear  in  a  box  at 
the  bottom  left  side  of  the  screen. 

If  participants  choose  to  receive  a  transmission,  that  data  will 
automatically  be  included  in  the  summary  box.  If  they  choose  to 
receive  a  message,  another  menu  will  come  up  asking  you  whether 
they  want  to  "Log"  this  message.  If  they  "Log"  the  message,  the 
message  will  be  written  into  their  "Log  File"  and  will  always  be 
available  to  them  to  read  by  choosing  the  "Log"  option  on  the 
"Measure"  menu.  If  they  do  not  want  a  permanent  record  of  this 
message,  they  can  use  the  arrow  key  to  highlight  "Don't  Log,"  hit 
RETURN  and  the  message  will  disappear.  If  participants  make  no 
response  to  this  message,  the  computer  will  automatically  not  Log 
the  message  after  ten  seconds. 

There  are  no  hot  keys  available  within  the  receive  function. 

The  Judcfment  Function.  If  the  participant  presses  the  ALT  key 
and  then  hits  "J,"  Judgment  will  be  highlighted.  If  the 
participant  then  hits  RETURN  (or  the  down  arrow  key)  a  menu  will 
come  up  that  gives  the  seven  possible  responses  to  make  toward  the 
target  (i.e..  Ignore,  Review,  Monitor,  Warn,  Ready,  Lock-On,  or 
Defend) .  For  all  but  the  CO  of  the  Carrier,  this  option  allows 
them  to  tell  the  team  leader  (i.e.,  the  Carrier)  what  they  think 
the  team  should  do  regarding  this  target.  If  a  participant  wants 
to  send  a  judgment,  he  or  she  can  use  the  arrow  keys  or  the  hot 
keys  to  highlight  the  decision  he  or  she  thinks  is  right  and  then 
hits  RETURN.  A  message  will  appear  in  the  bottom  right  portion  of 
the  screen  asking  the  participant  if  he  or  she  is  sure  that  this  is 
the  recommendation  they  want  to  make.  If  they  are  sure,  they  hit 
RETURN.  The  leader  will  immediately  receive  this  information.  In 
fact,  the  icon  representing  the  team  member  sending  the 
recommendation  will  turn  red  on  the  leader's  screen  and  the 
recommendation  will  be  typed  in  the  icon) .  Team  members  can  only 
send  one  recommendation,  so  they  should  wait  until  they  are  sure 
before  they  make  a  judgment. 

When  the  leader  (i.e.,  the  Carrier)  sends  his  or  her  judgment  this 
is  the  team's  official  decision,  and  this  ends  the  trial.  The  team 
leader  can  make  a  decision  even  if  all  the  other  members  have  not 
registered  their  recommendations,  and  the  leader  is  free  to  use  or 
disregard  these  recommendations  as  he  or  she  sees  fit.  If  the 
leader  fails  to  render  a  decision  before  time  runs  out,  the  team's 
decision  is  treated  as  an  IGNORE. 
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Decision  Outcome  and  Feedback 

When  the  trial  is  over,  all  team  members  will  receive  an  immediate 
report  telling  them  how  well  the  team  performed.  This  will  appear 
on  the  "feedback  screen,"  that  will  come  up  right  after  the  trial. 
The  Feedback  Screen  is  shown  in  Exhibit  12. 


Insert  Exhibit  12  here 


The  feedback  screen  informs  team  members  of  their  decision,  as  well 
as  the  "correct  decision."  There  are  five  possible  outcomes  from 
an  encounter,  and  the  team's  total  effectiveness  will  be  expressed 
in  terms  of  points  associated  with  each  outcome.  The  five  possible 
outcomes  are: 

HIT  -  A  hit  means  that  the  groups  decision  was  exactly  correct,  so 
for  example,  the  target  should  have  been  "warned"  and  that  was 
exactly  what  the  team  decided.  A  hit  is  worth  2  points  to  the 
team's  overall  score.  The  color  bars  at  the  top  and  bottom  of  the 
screen  will  be  green  when  this  occurs. 


HEAR  MISS  —  A  near  miss  means  that  the  team  was  off  by  one  place 
in  terms  of  their  aggressiveness  level.  For  example,  if  the  team 
decision  was  "warn,"  when  it  should  have  been  "monitor,"  this  would 
be  a  near  miss  (a  little  too  aggressive) .  It  would  also  be  a  near 
miss  if  the  team  decision  was  "warn"  when  they  should  have  been 
"ready"  (a  little  to  passive) .  Participants  are  told  that  a  near 
miss  is  a  pretty  good  outcome.  A  near  miss  is  worth  1  point.  The 
color  bars  at  the  top  and  bottom  of  the  screen  will  be  aquamarine 
when  this  occurs. 

MISS  —  A  miss  means  that  the  team  decision  was  off  by  two  places. 
This  is  worth  0  points.  The  color  bars  will  be  purple  when  this 
occurs . 

INCIDENT  —  An  incident  means  that  the  team  was  off  by  three  places 
in  their  response  to  the  target.  An  incident  means  that  the  team 
just  narrowly  avoided  disaster  (e.g.,  being  hit  itself  or 
mistakenly  shooting  down  a  friendly  target) .  This  outcome  results 
in  a  loss  of  1  point.  The  color  bars  will  be  red  when  this  occurs. 

DISASTER  —  A  disaster  means  that  the  team  decision  was  off  by  four 
places.  This  outcome  results  in  a  loss  of  2  points.  The  color 
bars  will  be  black  in  this  case. 

The  feedback  screen  provides  information  on  the  judgments  rendered 
by  the  other  team  members,  as  well  as  information  on  the  team's 
performance  history.  The  teams  goal  is  also  displayed  here,  where 


the  goal  is  expressed  in  terms  of  total  points  to  accumulate  over 
the  entire  session.  The  screen  also  provides  a  projection  of  what 
the  team's  total  score  will  be  at  the  end  of  a  session,  if  they 
continue  to  perform  at  their  current  level  of  proficiency. 

This  concludes  our  description  of  the  task  as  it  looks  from  the 
perspective  of  the  participants.  The  next  two  sections  will  focus 
on  the  task  from  the  point  of  view  of  the  experimenter.  The  first 
section  will  focus  on  how  to  construct  the  targets. 
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Establishing  Sets  of  Targets  with  TEAHSET. 

TEAMSET.EXE  is  a  support  program  in  TIDE^.  One  function  of 
TEAMSET.EXE  allows  the  experimenter  to  create  targets.  The  targets 
created  are  stored  in  a  file  called  TEAM??. INI,  where  the  ??  refer 
to  the  number  of  the  session  being  created  or  edited.  TIDE^  looks 
for  a  TEAM??. INI  file  every  time  it  is  initiated,  and  this  is  the 
means  by  which  experimenters  can  control  the  sets  of  targets  that 
are  seen  by  participants. 


Creating  Target  Files;  TEAM??. INI 

To  create  a  TEAM??. INI  file,  one  needs  to  be  in  the  TIDE^  directory 
and  then  type  TEAMSET,  and  hit  RETURN.  If  this  is  done,  the 
experimenter  is  presented  with  a  prompt.  This  prompt  will  ask  for 
the  "Parameter  File"  desired.  If  the  experimenter  wants  to  use  the 
default  version  of  the  simulation,  then  type  in  "TDWGTl"  and  hit 
RETURN.  "TDWGTl  is  the  default  Parameter  File  which  can  be  changed 
if  desired.  We  will  discuss  why  and  how  one  might  change  Parameter 
Files  in  a  later  section  of  this  report. 

After  one  has  entered  "TDWGTl",  a  new  screen  will  appear  presenting 
the  information  displayed  in  Exhibit  13.  To  create  targets  select 
"number  of  session  to  maintain"  and  hit  RETURN.  If  this  is  done, 
the  screen  will  then  appear  as  shown  in  Exhibit  14.  There  are 
several  features  of  this  screen  that  need  to  be  described. 


Insert  Exhibit  13  and  14  here 


Naming  TEAM??. INI  Files.  At  the  top  left  portion  of  the 
screen  you  see  "Games  set  title."  This  allows  the  experimenter  to 
place  a  verbal  label  on  that  INI  file  (e.g. ,  "Experiment  I,"  "All 
Ambiguous  Targets,"  "June  12,  1992,"  etc.).  This  is  optional  and 
the  program  will  function  if  this  is  left  blank.  To  change  or 
create  a  label  type  "41"  and  hit  RETURN.  Then,  at  the  prompt  enter 
the  name  you  wish  and  hit  RETURN.  The  name  entered  will  then 
appear  in  the  top  left  corner  of  the  screen. 

Setting  Goals.  At  the  top  right  hand  portion  of  the  screen, 
you  see  "Goal."  This  option  can  be  used  to  set  a  quantitative  goal 
for  each  team  member's  performance.  For  example,  if  there  are  to 
be  20  targets,  a  goal  of  20  (given  the  scoring  system  described  in 
the  previous  section) ,  implies  that  the  individual  or  team  needs, 
on  average,  a  near  miss  every  trial.  Since  the  carrier's  decision 
is  synonymous  with  the  team's  decision,  the  goal  for  the  carrier, 
is  in  fact,  the  team's  goal.  A  goal  of  30  would  be  more  difficult 
and  imply  that  participants  need  to  be  getting  near  misses  half  the 
time  and  hits  all  the  rest  of  the  time.  The  goal  is  optional  and 


the  program  will  function  if  it  is  set  to  0  or  left  blank.  If  the 
experimenter  wants  to  set  a  goal,  he  or  she  should  type  "42”  and 
then  hit  RETURN.  Then,  at  the  prompt,  type  in  the  goal  desired  for 
each  player  and  hit  RETURN.  When  entering  the  goal  for  each  player 
you  should  keep  two  things  in  mind.  First,  there  are  only  two 
spaces  allowed  for  the  goal  for  each  player  (thus  you  cannot  assign 
a  goal  of  120)  .  Second,  the  goals  need  to  be  entered  without 
spaces  between  the  values.  So  for  example,  if  we  wanted  the  Team's 
goal  (i.e.,  the  Carrier's  goal)  to  be  30,  while  the  other  team 
members'  goals  to  be  27,  at  the  prompt  we  would  enter  "30272727." 
This  goal  will  appear  in  the  upper  right  hand  corner  of  the  screen 
(see  Exhibit  14)  .  It  will  also  appear  on  the  participant's  feedback 
screen  every  time  that  screen  comes  up,  next  to  the  word  "Goal." 

Selecting  One  Plaver  or  Team  Versions.  Also  in  the  upper 
right  hand  corner  is  the  word  "Single."  If  the  researcher  is 
dealing  with  individual  decision  making,  then  he  or  she  should  type 
in  "43"  hit  RETURN,  and  then  enter  "Y"  and  hit  RETURN.  This  will 
invoke  the  default  "Single  Player"  version  of  the  simulation.  We 
will  have  more  to  say  about  the  "Single  Player"  version  of  TIDE^  in 
a  later  section  of  this  report.  If  the  researcher  is  dealing  with 
teams  or  groups,  he  or  she  should  type  "43,"  hit  RETURN,  and  then 
enter  "N,"  and  hit  RETURN  again.  This  will  invoke  the  default 
"Team"  version  of  the  simulation.  For  purposes  of  description 
here,  we  will  assume  that  the  researcher  is  conducting  studies  on 
teams. 

Setting  the  Game  Time.  Straight  below  the  "Single"  option  is 
the  "Game  Time"  function.  This  allows  the  experimenter  to 
manipulate  the  time  teams  will  have  to  respond  to  the  target  being 
created.  To  set  the  time,  type  "11"  and  hit  return.  At  this 
point,  the  experimenter  simply  types  in  the  number  of  seconds  that 
participants  will  have  to  make  a  decision  about  the  target  being 
created.  For  example,  120  seconds  is  a  relatively  short  time.  On 
the  other  hand,  360  seconds  gives  participants  a  long  time  to  make 
decisions  in  this  simulation. 


Setting  the  Feedback  Time.  Immediately  below  the  "Game  Time" 
function  is  the  "Feedback"  function.  This  controls  how  long  the 
feedback  screen  will  be  visible  between  trials.  Participants  in 
TIDE^  sessions  are  always  in  one  of  two  states  —  engaged  with 
targets  or  receiving  feedback.  Thus,  manipulating  feedback  time  is 
a  way  of  controlling  the  tempo  of  the  simulation.  Very  short 
durations  of  feedback  mean  that  targets  are  coming  one  right  after 
another.  Long  periods  of  feedback  break  up  targets  and  give 
participants  time  to  rest,  communicate  with  each  other  through  text 
messages,  or  peruse  their  log  file. 
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Setting  Target  Attributes 

All  the  remaining  parts  of  the  screen  deal  with  the  actual 
construction  of  targets.  There  are  many  different  ways  to  create 
targets  depending  upon  the  need  of  the  particular  study  being 
conducted.  We  will  describe  four  different  ways.  Before  we  do 
this,  however,  we  need  to  make  the  important  distinction  between 
"Raw  Values"  and  "Cue  Values." 

"Raw  Values  are  in  the  scale  of  the  attribute  and  vary  in  range  for 
each  attribute.  That  is,  in  raw  values.  Speed  ranges  from  200  to 
800  and  is  described  in  a  scale  of  miles  per  hour  (mph) .  Altitude, 
in  raw  values  ranges  from  5,000  to  30,000,  and  is  described  in  a 
scale  of  feet.  "Cue  Values,"  on  the  other  hand,  refer  to 
translations  of  raw  values  into  their  respective  degrees  of  threat. 
"Cue  Values"  all  have  the  same  range  and  scale,  taking  on  values  of 
0,  1  or  2  (for  non-threatening,  somewhat  threatening,  and  very 
threatening  respectively)  .  In  some  instances,  the  experinenter  may 
wish  to  create  targets  by  entering  "Raw  Values,"  and  in  other 
cases,  the  experimenter  may  wish  to  create  targets  using  "Cue 
Values."  With  this  distinction  in  place,  we  will  now  descr..be  the 
four  means  of  creating  targets. 

Creating  targets  with  Randomized  Cues.  First,  there  may  be 
conditions  when  the  experimenter  wishes  to  create  targets  where  the 
cues  values  associated  with  these  targets  are  orthogonal  (i.e.,  the 
nine  target  dimensions  are  all  unrelated).  To  do  this,  at  the 
"Your  Choice"  prompt,  type  "lOR"  and  hit  RETURN  two  times.  The 
program  will  generate  values  itself,  drawing  from  a  random 
population  of  values  for  each  of  the  nine  cues.  Over  a  large 
number  of  targets,  this  process  will  generate  a  context  where  the 
cues  are  orthogonal. 

There  is  one  important  point  to  note  about  creating  targets  made  up 
of  orthogonal  cues;  the  resulting  targets  will  not  be  randomly  or 
rectangularly  distributed,  but  rather  skewed  toward  higher  values. 
In  other  words,  employing  this  method  in  creating  targets  will  lead 
to  a  large  number  of  "safe  targets"  (i.e.,  Ignore,  Review  and 
Monitor)  and  very  few  "threatening  targets"  (i.e..  Ready,  Lock-on 
or  Defend) .  This  occurs  because  of  the  interactive  nature  of  the 
cues  associated  with  the  initial  version  of  the  simulation.  If  any 
cues  that  are  components  of  combination  rules  take  on  a  value  of  0, 
the  value  attributable  to  that  combination  goes  to  0,  regardless  of 
the  value  for  the  other  cue.  For  example,  if  speed  is  low  (e.g. 
raw  value  of  290  mph  and  cue  value  of  0)  ,  the  target  is  non¬ 
threatening  according  to  the  "Speed-Direction"  combination  rule 
regardless  of  the  value  for  direction  (i.e.,  even  if  the  target  is 
coming  straight  in  at  0  degrees  —  a  cue  value  of  2  —  the  Speed- 
Direction  interaction  is  0) . 


TIDE^ 

27 

Creating  Targets  with  Randomized  Outcomes.  Since  random  cues 
do  not  generate  random  outcomes,  there  is  also  an  option  available 
to  create  targets  that  are  randomly  distributed  in  terms  of  "True 
Score.”  To  do  this,  at  the  "Your  Choice”  prompt  type  "10”  and 
then  hit  RETURN  twice.  This  creates  a  set  of  targets  whose  true 
scores  are  randomly  distributed. 

It  should  be  stressed  here,  that  if  the  targets  are  randomly 
distributed,  the  cues  associated  with  these  targets  will  not  be 
orthogonal.  Experimenters  need  to  carefully  think  through  whether 
they  want  independent  cues  or  independent  outcomes. 

Manually  Specifying  Cue  Values.  In  other  cases,  experimenters 
may  be  interested  in  neither  randomly  generated  cues  or  randomly 
generated  targets,  and  instead  may  wish  to  create  specific  targets. 
Thus  a  third  way  to  create  targets  is  to  directly  enter  cue  values. 
To  do  this,  at  the  prompt  "Your  Choice,”  type  ”10”  and  RETURN  once. 
Then  just  enter  the  nine  cue  values  (either  0,  1  or  2)  that  you 
want  for  this  target,  where  the  first  nvunber  represents  the  first 
cue  (i.e..  Speed),  and  the  second  number  represents  the  second  cue 
(i.e..  Altitude)  and  so  on. 

Thus,  entering  "222222222”  will  create  a  target  that  is  very 
threatening,  and  participants  should  choose  "Defend.”  Entering 
”000000000"  will  create  a  target  that  is  very  non-threatening,  and 
participants  should  choose  "Ignore."  Entering  ”111111111”  will 
generate  an  intermediate  target  that  participants  should  "Monitor.” 
By  playing  with  different  patterns  of  cue  values,  the  experimenter 
can  create  any  kind  of  target  he  or  she  wishes. 

Manually  Specifying  Raw  Attribute  Values.  A  fourth  and  final 
way  of  creating  targets  is  to  specify  the  exact  raw  values  that  are 
desired  for  every  cue.  For  example,  at  the  "Your  Choice”  prompt, 
if  the  experimenter  wants  a  specific  speed  for  this  target,  (e.g. 
800  mph)  type  ”1”  and  RETURN.  The  program  will  ask  for  the  value 
desired,  at  which  point  the  experimenter  types  ”800”  and  then 
RETURN.  That  raw  value  will  appear  on  the  screen  immediately, 
along  with  the  appropriate  cue  value  (i.e.,  2).  If  the 
experimenter  then  wants  to  specify  the  raw  value  for  Direction,  he 
or  she  could  type  ”6”  and  hit  RETURN  at  the  "Your  Choice”  prompt. 
The  experimenter  then  enters  the  raw  value  for  direction  desired 
(e.g.,  02  degrees)  and  then  hits  RETURN.  The  cue  value  associated 
with  this  raw  value  (i.e.,  2)  then  appears  on  the  screen. 

The  program  will  not  allow  the  experimenter  to  plug  in  a  raw  value 
that  is  out  of  range  (e.g..  Speed  of  2,000  mph.  Direction  of  90 
degrees,  etc.). 

It  is  important  to  note  that  the  screen  that  the  experimenter 
manipulates  displays  both  the  raw  data  in  the  scale  associated  with 
the  cue  (e.g. , mph,  meters,  ft.,  etc.)  and  the  cue  value.  Only  the 
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raw  values  are  seen  by  participants  when  they  are  engaged  in  the 
simulation.  The  cue  values  are  never  seen  by  the  participants. 
This  is  the  value  they  need  to  infer  based  upon  the  raw  value  they 
see  and  the  expertise  that  they  have  obtained  through  training. 

Returning  to  the  TEAMSET  screen,  just  below  the  ninth  cue  is  the 
"Correct  Decision"  (i.e..  Ignore,  Waim,  Defend,  etc.).  This  serves 
as  the  criterion  against  which  the  team's  decision  will  be 
compared.  This  is  computed  automatically  by  the  program. 
Experimenters  do  not  type  in  the  "Correct  Decision"  directly.  This 
can  only  be  set  in  one  of  the  four  ways  just  described.  In  other 
words,  there  is  no  option  for  an  experimenter  to  request  a  "Defend” 
and  then  have  the  computer  generate  it. 


Experimenters  can  mix  and  match  targets  creating  processes  to  come 
up  with  a  single  target.  For  example,  at  the  "Your  Choice"  prompt, 
one  could  type  in  "lOR"  and  hit  RETURN  twice  and  get  a  target  with 
randomly  generated  cues.  Then  the  researcher  could  type  "1"  and 
hit  RETURN  to  change  the  randomly  generated  Speed  value  to  some 
other  desired  value. 

Sample  Configurations  of  Targets.  Exhibit  15  shows  the 
configuration  for  several  different  types  of  targets  that  may  be  of 
interest  to  decision  making  researchers.  Some  of  these  like  (a)  a 
sure  Defend  and  (b)  a  sure  Ignore  have  been  discussed  already. 
Targets  (c)  and  (d)  show  two  different  ways  of  getting  to  a  "Warn." 
In  (c)  the  target  is  somewhat  threatening  on  most  dimensions,  and 
it  is  this  feature  of  the  configuration  that  results  in  a  "Warn." 

The  configuration  in  (d)  also  generates  a  target  that  should  be 
warned,  but  in  this  case,  the  target  is  very  threatening  on  some 
attributes  but  not  threatening  at  all  on  other  attributes. 


Insert  Exhibit  15  here 


Often  experimenters  are  interested  in  reactions  to  targets  that  are 
ambiguous  on  one  or  more  dimensions.  In  the  initial  version  of 
this  simulation,  the  participants  training  on  cues  leaves  a  range 
of  values  that  are  somewhat  indeterminate  as  to  their  degree  of 
threat.  For  example,  if  you  turn  back  to  Exhibit  7,  8,  9,  and  10, 
you  can  see  that  there  are  "grey  zones"  associated  with  all  cues. 
For  example  a  speed  of  500  falls  in  a  grey  zone  between  "somewhat 
threatening"  and  "very  threatening."  Similarly,  25,000  ft  falls 
somewhere  between  "non-threatening"  and  "somewhat  threatening"  on 
altitude.  Thus,  although  it  is  clear  to  the  program  at  what  point 
the  cue  goes  from  one  state  to  another  (e.g.,  non-threatening  to 
somewhat  threatening) ,  this  is  not  always  clear  to  the  participants 
because  of  their  instructions.  Thus,  by  specifying  the  exact  raw 
value  for  each  cue,  and  placing  this  in  a  grey  zone,  the 
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experimenter  can  create  a  relatively  ambiguous  target,  such  as  that 
depicted  in  (e) .  Both  (a)  and  (e)  call  for  the  exact  same  decision 
(i.e..  Defend),  but  (e)  is  much  more  ambiguous  relative  to  (a). 

Experimenters  can  also  use  these  grey  zones  to  create  targets  that 
are  "deceiving."  An  example  of  this  is  shown  in  (f) .  Here  the 
target  is  obviously  very  threatening  on  the  first  four  dimensions. 
On  the  last  four  dimensions,  however,  the  target  is  non¬ 
threatening,  but  in  a  relatively  ambiguous  manner  (i.e.,  cue  values 
of  0  but  raw  values  in  grey  zones) .  Thus,  all  combination  rules  go 
to  0,  giving  the  target  a  value  of  2  (due  to  IFF)  and  thus  an 
"Ignore."  This  will  not  look  like  an  "Ignore"  to  most 
participants.  Instead,  it  will  appear  to  be  much  more  threatening 
than  it  truly  is. 

Experimenters  can  also  generate  "conflict  generating"  targets  that 
look  one  way  to  some  team  members,  but  look  entirely  different  to 
other  team  members.  For  example,  the  target  shown  in  (g)  appears 
to  the  CAD,  based  on  what  he  or  she  can  measure,  to  be  very 
threatening.  On  the  other  hand,  the  target  as  it  appears  to  the 
AWAC  is  much  less  threatening.  Under  these  kinds  of  conditions,  it 
would  not  be  unusual  to  find  the  CAD  making  recommendations  that 
look  overly  aggressive  to  the  AWACs,  and  recommendations  from  the 
AWACs  that  look  overly  passive  to  the  CAD. 

These  are  just  a  sample  of  the  kinds  of  experimental  variables  that 
can  be  manipulated  with  targets  via  TEAMSET. 

One  feature  of  TIDE^  that  may  limit  some  researchers  is  the 
inability  to  make  targets  change  during  a  trial.  Dynamic  targets 
can  be  simulated  via  TIDE^  through  instructions  and  manipulation  of 
the  feedback  screen,  however.  So  for  example,  participants  could 
be  told  that  an  overall  trial  for  a  specific  target  is  actually  5 
sub-trials,  where  the  participants  need  to  make  preliminary 
judgments  at  each  sub-trial.  The  experimenter  can  then  go  into 
TEAMSET  and  create  targets  in  blocks  of  5.  In  doing  so,  the 
experimenter  may  want  to  follow  a  rule  that  a  target  can  only 
change  on  some  dimensions  (e.g.,  speed,  altitude,  angle,  direction, 
corridor  status,  and  range) ,  and  that  the  target  can  only  go  from 
one  state  (e.g.,  threatening)  to  an  adjacent  state  (somewhat 
threatening)  between  sub-trials.  Thus,  through  a  series  of  sub¬ 
trials,  the  experimenter  can  create  a  target  that  starts  out  non¬ 
threatening,  and  then  slowly  turns  threatening,  or  vice  versa. 
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Establishing  Context  Effects  with  Targets  in  TEAMSET 

By  manipulating  a  set  of  targets  created  via  TEAMSET,  an 
experimenter  can  create  several  contextual  effects  that  are  often 
relevant  to  researchers  in  decision-making  or  team  behavior.  We 
will  specifically  examine  nine  of  these. 


Manipulating  Base  Rate 

In  the  decision  making  literature,  base  rate  refers  to  the  a  priori 
probability  that  the  criterion  will  be  of  one  type  versus  another. 
In  this  context,  a  set  of  targets  can  be  generated  so  that  the 
field  is  dominated  by  almost  all  "threatening"  or  all  "non¬ 
threatening"  targets.  In  this  overall  field,  one  can  then 
introduce  "ambiguous"  or  "deceiving"  targets  and  see  how 
participants  reactions  are  affected  by  the  base  rate. 

For  example,  Hollenbeck,  Sego,  Ilgen,  and  Major  (1991)  randomly 
assigned  participants  to  either  a  threatening  base  rate  or 
rectangular  base  rate  conditions.  In  the  threatening  base  rate 
condition  all  but  four  of  21  targets  were  Defends  or  Lock-ons.  In 
the  rectangular  base  rate  condition  there  was  an  equal  number  of 
all  seven  possible  outcomes.  They  then  studied  how  the  exact  same 
four  "non-threatening  targets"  were  responded  to  by  teams  that 
varied  in  their  base  rate  for  targets.  Decision  making  theory 
would  suggest  that  the  same  four  targets  would  prove  much  more 
difficult  for  participants  in  the  threatening  base  rate  condition 
than  in  the  rectangular  condition. 


Creating  Group  Conflict 

Group  conflict  is  a  condition  where  there  are  multiple  instances  of 
different  team  members  coming  to  different  opinions.  By  generating 
"conflicting  targets"  in  the  manner  described  in  the  previous 
section,  it  is  possible  to  generate  a  context  where  two  team 
members  are  often  likely  to  disagree.  Researchers  can  then  examine 
what  effect  this  has  on  team  outcomes  and  processes. 

For  example,  in  Hollenbeck  et  al.  (1991),  participants  were 
randomly  assigned  to  two  conditions  where  the  outcomes  associated 
with  targets  were  identical,  but  where  the  nature  of  cues  leading 
up  to  those  outcomes  was  varied.  In  the  conflict  condition,  the 
CAD  and  AWACs  participants  were  provided  with  information  that  was 
as  conflicting  as  possible  given  the  constraints  Inherent  in 
keeping  the  overall  criterion  matched  with  control  participants. 
They  then  examined  how  these  Individuals  rated  each  other,  the 
communication  patterns  they  displayed  with  each  other,  and  how 
other  members  (e.g.,  the  leader)  reacted  to  both. 


Creating  Amblcmitv  in  Targets 


TIDE^ 

31 


In  the  previous  section  we  described  a  process  to  generate  targets 
that  will  appear  ambiguous  to  participants.  By  employing  only 
ambiguous  targets,  one  can  see  how  ambiguity  in  the  task  affects 
team  outcomes  and  processes.  For  example,  in  Hollenbeck  et  al. 
(1991)  participants  were  randomly  assigned  to  two  conditions,  where 
the  cue  values  and  criterion  values  were  equal  for  each,  but  where 
the  raw  values  for  targets  either  (a)  all  fell  in  "grey  zones"  for 
teams  in  one  condition,  or  (b)  all  fell  within  established  ranges 
for  teams  in  the  other  condition.  They  then  examined  what  impact 
this  had  on  perceptions  of  uncertainty,  stress,  communication 
patterns ,  and  outcomes . 


Manipulating  Stress  Through  Time  Pressure 

Stress  is  typically  conceived  as  a  negative  emotional  reaction  and 
concomitant  physiological  change  in  a  person  that  occurs  when 
someone  is  confronted  with  a  challenge  or  problem.  Stress  is 
particularly  acute  under  conditions  where  there  is  uncertainty 
regarding  one's  capacity  to  alleviate  or  meet  the  demand  imposed  by 
the  threatening  stimulus  (McGrath,  1976) .  In  this  simulation, 
stress  is  manipulated  by  varying  the  amount  of  time  pressure 
associated  with  specific  targets.  Thus,  by  decreasing  the  amount 
of  time  associated  with  a  given  trial,  stress  levels  for 
participants  should  be  higher. 

For  example,  Hollenbeck  et  al.  (1991)  ran  teams  in  six  conditions 
where  the  amount  of  time  that  they  had  to  respond  to  targets  was 
varied,  but  where  the  targets  themselves  were  a  constant.  In  one 
condition  participants  experienced  little  time  pressure  throughout 
the  experiment  ( i .  e . ,  they  had  five  minutes  to  respond  to  each 
target) ,  whereas  in  another,  participants  experienced  a  great  deal 
of  time  pressure  (i.e.,  they  were  given  two  minutes  with  each 
target) .  In  the  third  and  fourth  conditions,  participants 
experienced  either  increasing  or  decreasing  time  pressure 
throughout  the  experiment.  Finally,  in  the  two  remaining 
conditions  participants  were  give  high  or  low  time  pressure  but 
under  conditions  where  all  targets  were  ambiguous  on  all 
dimensions. 

This  design  allowed  Hollenbeck  et  al.  (1991)  to  test  the  effects  of 
time  pressure  on  stress  both  within  and  across  teams.  It  also 
allowed  an  exploration  of  the  affects  of  ambiguity  on  stress 
independent  of  time  pressure.  Stress  was  measured  in  terms  of 
participants  perceptions,  as  well  as  through  physiological  measures 
of  stress  taken  with  robotic  vital  signs  monitors  attached  to 
participants.  Hollenbeck  et  al.  (1991)  also  examined  the  degree  to 
which  time  pressure  affected  group  outcomes  and  processes. 
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Manipulating  Task  Complexity 

In  his  conceptual  treatment  of  task  complexity.  Wood  (1986) 
identified  three  primary  dimensions  of  task  complexity:  component 
complexity,  coordinative  complexity  and  dynamic  complexity.  The 
first  two  of  these  can  be  manipulated  through  the  judicious  use  of 
target  creation  in  TEAMSET  program. 

Component  complexity  in  Wood's  system  deals  with  the  sheer  number 
of  pieces  of  information  that  need  to  be  processed  to  perform  the 
task.  This  type  of  complexity  can  be  manipulated  by  yoking  the 
values  of  separate  dimensions,  so  that  knowledge  on  one  gives 
precise  knowledge  about  the  value  of  another.  By  yoking  cues,  one 
can  take  the  initial  version  of  the  simulation  which  has  nine 
attributes  and  convert  it  into  a  system  that  really  has  only  5 
unique  attributes  (since  knowledge  on  four  gives  precise  knowledge 
on  four  others) . 

For  example,  Hollenbeck  et  al.  (1991)  randomly  assigned  teeuns  to 
two  conditions,  one  where  there  were  nine  orthogonal  dimensions, 
and  another  where  the  "combination  cues"  were  yoked.  Specifically, 
the  targets  were  created  in  the  yoked  condition  in  such  a  manner 
that  if  the  target  was  threatening  on  one  dimension,  it  was  equally 
threatening  on  whatever  dimension  worked  in  combination  with  the 
first  dimension  (e.g.  if  it  was  threatening  on  Speed,  it  was  also 
threatening  on  Direction) .  Participants  were  informed  of  this  and 
thus  the  nine  cue  task  was  effectively  turned  into  a  five  cue  task 
(i.e.,  IFF  and  the  four  combination  rules). 

A  second  type  of  complexity  identified  by  Wood  is  coordinative 
complexity.  This  deals  with  the  complexity  in  how  the  various 
pieces  of  information  interact.  Yoking  cues  impacts  this  dimension 
of  complexity  since  perfect  confounding  of  the  combination  cues 
destroys  the  interactive  nature  of  these  cues  (i.e.,  within  an 
interaction,  one  "non-threatening"  cue  cannot  cancel  out  a 
"threatening"  cue) . 


Manipulating  Tempo 

There  are  two  kinds  of  pressure  created  by  time  in  this  simulation. 
One  deals  with  the  time  available  to  respond  to  targets,  and  the 
other  deals  with  tempo,  that  is,  the  time  between  targets  (i.e., 
the  time  the  Feedback  Screen  is  displayed)  .  In  fast  tempo 
environments,  one  target  follows  another  in  quick  succession. 
There  is  little  time  to  rest  or  reflect  between  trials.  This  can 
be  manipulated  in  this  simulation  by  varying  the  time  available  to 
examine  feedback.  Short  duration  (e.g.,  ten  seconds)  feedback 
screens  create  a  fast  tempo,  whereas  long  duration  (e.g.,  30 
seconds)  feedback  screens  create  a  slow  tempo. 
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Establishing  Prototypes 

In  cognitive  psychology,  a  "prototype"  is  a  simplistic  frame  used 
to  interpret  and  make  sense  of  more  complex  information  (Lord, 
1985) .  So  for  example,  if  someone  suggests  that  another  person  is 
a  "yuppie,"  this  conjures  up  an  image  in  the  listener's  mind  about 
what  the  person  will  probably  be  like  on  a  number  of  dimensions 
such  as  "profession,"  "political  attitudes,"  "dress  and  demeanor," 
"purchasing  preferences,"  etc.  In  the  TIDE^  simulation,  one  can 
create  prototypes  by  generating  targets  that  are  categorical  in 
nature . 

For  example,  the  environment  that  a  participant  encounters  may  be 
made  up  of  only  four  kinds  of  targets  (fighters,  bombers,  airliners 
and  corporate  jets)  each  of  which  can  assume  only  two  states  (e.g., 
an  attacking  fighter  vs.  an  innocent  fighter  flyover  or  a  lost 
corporate  jet  vs.  a  kamikaze  corporate  jet,  etc.).  In  this  kind  of 
context,  the  participant's  task  is  to  sort  targets  into  categories 
depending  upon  critical  attributes  of  the  target.  Some  of  the 
attributes  may  overlap  across  categories  (e.g.,  an  innocent  fighter 
flyover  and  kamikaze  corporate  jet  are  similar  on  some  dimensions 
such  as  Size  and  Speed),  but  differ  on  others  (e.g..  Radar  and 
IFF) .  The  development  and  use  of  these  kinds  of  prototypes  often 
separates  experts  from  novices  and  may  be  of  interest  to 
researchers  in  team  decision-making. 


Creating  Trends.  Cycles  and  Seasonality 

"Trends"  refer  to  relationships  within  experimental  sessions 
between  adjacent  targets.  "Trends"  can  be  established  by  creating 
targets  that  steadily  increase  or  decrease  in  terms  of  their  threat 
level  during  the  duration  of  the  experiment. 

"Cycles"  can  be  established  by  creating  and  then  changing  the 
direction  of  trends  systematically.  Thus,  targets  can  increase  in 
their  level  of  threat  up  to  some  point,  then  begin  to  decrease  up 
to  some  point  and  then  start  up  again. 

"Seasonality"  can  also  be  established  by  having  the  degree  of 
threat  covary  with  some  unit  of  time.  For  example,  trials  can  be 
described  as  seasons,  in  that  the  first  ten  are  summer,  the  next  10 
are  fall,  etc.  Scenarios  can  be  written  around  these  to  suggest 
that  hostility  levels  are  always  low  in  winter. 

In  summary,  this  section  has  described  and  shown  a  number  of  ways 
to  use  the  initial  version  of  TIDE^  for  various  kinds  of  team 
research,  where  the  task  and  scenario  are  as  described  above.  That 
is,  the  context  is  a  naval  air  patrol  context  where  there  are  these 
specific  nine  cues,  that  combine  in  these  specific  five  ways  to 
generate  one  of  these  seven  criterion  decisions.  In  all  cases. 
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four  players,  measure  these  specific  cues,  and  communicate  in 
specific  fashions  to  reach  one  of  seven  possible  decisions. 

TIDE^  is  a  much  more  flexible  program  than  is  implied  so  far.  We 
will  focus  on  its  flexibility  in  the  next  section.  First  we  will 
show  how  to  change  the  nature  of  the  task  while  maintaining  the 
naval  air  patrol  scenario.  In  the  next  sub-section  we  will  show 
how  to  change  the  nature  of  the  scenario  so  that  it  has  nothing  to 
do  with  air  patrol. 
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Changing  the  Task  and  Scenario 

Recall  from  Exhibit  13  that  the  menu  screen  in  TEAHSET  comes  with 
two  primary  options: 

"W  to  modify  weights  and  values”  —  which  makes  desired 
changes  in  the  "initial  version”  of  the  simulation,  and 

”##  of  session  to  create  or  maintain”  —  which  creates  or 
changes  targets. 

Up  until  this  point,  we  have  been  only  dealing  with  the  option  for 
creating  and  changing  targets.  If  one  wishes  to  change  the  initial 
version  of  the  simulation,  the  first  option  shown  in  Exhibit  13 
should  be  selected. 


Changing  the  Task  with  TEAMSET 

For  a  moment,  assume  you  are  indifferent  to  the  naval  Command  and 
Control  scenario  but  wish  to  modify  the  underlying  task  in  some 
manner  that  differs  from  the  initial  version  of  the  simulation.  We 
will  use  a  running  example  to  show  how  many  different  changes  can 
be  made  and  accumulated  in  TIDE^,  so  that  when  finished,  the 
researcher  has  a  personally  tailored  simulation  that  differs  from 
the  "initial  version.”  Enter  TEAMSET,  and  at  the  prompt  choose  ”W” 
for  "modify  weights  and  values.”  When  this  is  accomplished,  you 
will  see  the  screen  shown  in  Exhibit  16a  and  16b.  These  screens 
will  be  referred  to  as  the  "Measures  Screen,”  and  the 
Communications  Screen”  respectively. 


Insert  Exhibit  16a  and  16b  here 


The  Measures  Screen .  Each  bracketed  number  in  that  screen 
corresponds  to  an  aspect  of  TIDE^  that  can  be  manipulated.  We  will 
discuss  each  of  these  in  turn,  focusing  on  the  goal  of  keeping  the 
air  patrol  scenario  but  changing  specific  facets  of  the  task. 

[1]  #  Measures  —  This  feature  allows  the  experimenter  to  change 
the  number  of  cues  that  comprise  that  simulation.  The  initial 
version  has  9,  which  is  the  maximum,  but  an  experimenter  can  opt 
for  less  than  this.  For  example,  if  you  type  ”1”,  then  hit  RETURN, 
and  then  type  ”6”,  and  hit  RETURN.  This  creates  a  six  cue  task. 

[2]  #  Interactions  —  There  are  four  interactions  or  combination 
rules  in  the  initial  version  of  the  simulation  (i.e..  Attribute  1 
combines  with  Attribute  6,  etc.).  This  is  the  maximum  allowed, 
however,  this  number  can  be  reduced  to  0  interactions.  For  example, 
if  you  type  ”2”,  then  hit  RETURN,  and  then  type  ”0”,  and  hit 
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RETURN.  Now,  we  have  created  a  version  of  the  simulation  where 
there  are  no  interaction  or  combinations  of  attributes. 

[3]  #  Judgments  —  In  the  initial  version  of  the  simulation,  their 
are  8  possible  judgments  that  can  be  made.  Seven  of  these  have 
been  described  already  (i.e..  Ignore,  Review,  Monitor,  Warn,  Ready, 
Lock-on,  Defend)  .  In  addition  to  these,  the  program  also  generates 
a  "No  Call"  for  participants  who  fail  to  make  a  recommendation  or 
decision  in  the  time  allowed.  This  is  treated  as  an  "Ignore"  by 
the  computer  in  determining  decision  accuracy,  but  for 
informational  reasons,  it  is  differentiated  from  Ignore  when 
participants  get  their  feedback.  Eight  is  the  maximum  number  of 
decisions  allowed,  but  an  experimenter  can  use  fewer.  For  example, 
typing  "3",  hitting  RETURN,  and  then  typing  "2",  and  hitting 
RETURN,  will  lead  to  a  simulation  where  the  decision  is  a 
dichotomy. 

[4]  #  Outcomes  —  In  the  initial  version  of  TIDE^  there  are  5 
decision  outcomes  (Hit,  Near  Miss,  Miss,  Incident,  and  Disaster) . 
This  is  the  maximum  number  of  discrete  outcomes.  This  number  can 
be  reduced  as  low  as  2,  however.  For  example,  typing  4,  hitting 
return,  and  then  2  will  lead  to  this  many  outcomes. 

[5]  #  Icons  —  There  are  four  icons  on  that  appear  on  the  screen  in 
the  initial  version  of  TIDE^.  This  is  the  maximum,  although  it  can 
be  reduced.  Typing  5,  then  hitting  RETURN,  and  then  3  would  create 
a  screen  with  space  for  only  three  icons. 

[6]  Message  wait  time  —  The  CPU  of  the  computers  running  TIDE^ 
needs  to  do  two  major  tasks.  First,  it  needs  to  interact  with  the 
Team??. INI  files  that  contain  the  targets  so  participants  can 
measure  and  record  target  attributes.  However,  the  CPU  also  has  to 
leave  this  aspect  of  the  simulation  to  search  for  messages  from 
other  players  that  reside  on  the  network.  The  message  wait  time 
function  allows  the  experimenter  to  determine  how  often  the  CPU 
goes  looking  for  messages.  This  has  some  non-trivial  implications 
for  the  simulation. 

If  the  message  time  is  set  very  low,  for  example  .10  seconds,  then 
the  CPU  is  often  "not  home"  at  the  instant  the  participants  hit  the 
ALT  key  to  activate  the  Menu  Bar.  If  this  occurs,  the  Menu  Bar  is 
not  highlighted,  and  participants  cannot  measure  target  attributes. 
This  is  frustrating  for  participants  who  seem  to  expect  immediate 
action  from  their  response  (even  when  informed  otherwise) 
especially  in  high  pressure  trials.  The  advantage  of  short  wait 
times  is  that  messages  are  received  virtually  the  moment  they  are 
sent. 

If  the  message  wait  time  is  set  very  high,  for  example  10.0 
seconds,  then  just  the  opposite  problem  results.  Participants  can 
get  immediate  access  to  the  Menu  Bar  following  their  ALT  key  input. 
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However,  the  time  between  sending  a  message  and  receiving  one  gets 
inordinately  long.  For  example,  it  could  take  ten  seconds  to  send 
a  message,  and  then  another  ten  seconds  to  receive  one's  answer, 
which,  in  a  150  second  trial,  may  be  too  slow  to  be  useful.  This 
too  can  be  frustrating  for  participants. 

In  pilot  tests,  we  have  found  that  three  seconds  provides  a  good 
balance  between  these  two  sources  of  frustration.  Other 
experimenters  may  have  reasons  for  making  different  decisions 
(e.g.,  vary  the  delay  or  cost  associated  with  communication)  so 
this  can  be  modified.  For  example,  if  you  type  "6",  hit  RETURN, 
and  then  type  "8",  and  hit  RETURN.  Now,  the  CPU  will  look  to  the 
network  for  messages  every  eight  seconds.  We  will  talk  about  this 
again  when  we  discuss  hardware  requirements  for  TIDE^. 

[7]  Cue  weights  —  Although  no  label  is  provided,  option  7  exists 
to  manipulate  the  weights  assigned  to  cues.  For  example,  if  you 
turn  back  to  Exhibit  I6a,  you  can  see  that,  in  the  initial  version 
of  the  simulation,  only  one  cue  (i.e.,  IFF,  Cue  #5)  gets  a  non-zero 
weight  (it  gets  a  weight  of  2).  This  can  be  seen  in  the  initial 
"Modify  Weights  and  Values"  screen  where  down  the  column  under  [7], 
all  values  but  #5  are  set  to  0.  This  can  be  changed,  however,  if 
the  experimenter  is  interested  in  having  a  large  nvimber  of  "main 
effect"  cues.  For  example,  the  task  we  are  currently  modifying  has 
six  cues,  with  no  interactions  used  to  make  a  dichotomous  decision. 
If  the  experimenter  types  "7",  hits  RETURN,  and  then  enters 
"mill",  all  six  cues  created  will  be  unit-weighted  in  generating 
the  criterion  value.  That  is,  the  mathematical  expression  for 
generating  criterion  values  will  become: 

[4]  Y  =  (DX,  +  (DXj  +  (DXj  +  (DX^  +  (DXj  +  (DX^ 

It  is  important  to  note  that  whenever  the  experimenter  wishes  to 
change  any  weight,  all  weights  must  be  entered  after  the  [7] 
prompt.  That  is,  if  we  now  wanted  to  go  back  and  double  the 
weights  on  the  first  three  attributes,  we  would  need  to  enter 
"222111." 

[8]  Attribute  Labels  —  Although  no  label  is  provided,  option  8 
refers  to  the  label  attached  to  the  Attribute  numbered  #1,  #2,  etc. 
If  an  experimenter  wanted  to  change  the  name  of  an  attribute,  this 
could  be  accomplished  with  this  option.  For  example,  if  the 
experimenter  disliked  Attribute  #5's  current  label  (i.e.,  IFF)  he 
or  she  could  change  it  to  something  else.  As  with  option  [7],  if 
the  researcher  wishes  to  change  any  attribute  label,  all  must  be 
re-entered. 

For  example,  if  one  wishes  to  only  change  IFF,  then  one  must  do  the 
following.  First,  type  "8",  and  then  hit  RETURN.  This  will  invoke 
the  screen  shown  in  Exhibit  17a.  Since  Speed  is  not  to  be  changed, 
simply  type  Speed  and  then  hit  RETURN.  Exhibit  17b  will  then  be 
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presented.  Since  it  is  also  desired  to  keep  Altitude,  simply  type 
Altitude,  and  then  hit  RETURN.  Continue  to  type  in  the  labels  you 
wish  to  leave  unchanged,  until  you  get  to  IFF.  At  this  point,  the 
screen  will  appear  as  it  does  in  Exhibit  17c.  Now  type  in  the  new 
label  you  wish  to  replace  IFF  with.  For  example,  type  in 
"Emissions”  if  that  is  the  new  label  desired,  and  then  hit  RETURN. 
At  this  point,  the  screen  will  appear  as  shown  in  Exhibit  17d.  All 
one  needs  to  do  now,  is  enter  the  label  for  the  last  attribute. 
Direction.  Since  this  is  to  be  unchanged,  follow  the  procedure 
discussed  above  for  re-typing  attribute  names.  Hitting  return 
after  entering  "Direction,"  since  this  is  the  last  cue,  returns  you 
to  the  Measures  Screen,  which  now  reveals  the  new  label  for 
Attribute  #5. 


Insert  Exhibit  17a,  17b,  17c,  and  17d  here 


[9]  "Hot"  letter  key  —  Earlier  we  discussed  two  ways  of  selecting 
attributes  to  be  measured.  First,  moving  up  and  down  in  the 
Measurement  box  using  the  arrow  keys,  highlighting  the  desired 
attribute  and  then  hitting  RETURN.  Second,  one  can  also  simply 
type  in  the  "hot  key,"  associated  with  a  given  attribute  (i.e.,  the 
red  letter  within  each  attribute  label).  For  example,  typing  "z" 
for  a  quick  measure  of  Size. 

Option  9  allows  you  to  determine  which  letter  will  be  hot  wired  in 
this  fashion.  As  with  other  options,  if  you  wish  to  change  one 
"hot  key,"  you  must  re-enter  all  of  them.  TO  change  it,  enter  the 
number  representing  the  location  of  the  letter  in  the  word.  So  for 
example  if  you  wanted  to  make  it  so  that  "s"  was  the  hot  letter  for 
"Size"  (rather  than  for  "Speed")  you  would  change  the  third  hot  key 
(which  made  "z"  the  hot  letter  for  "Size")  to  1.  At  the  same  time, 
you  would  need  to  go  back  and  change  the  hot  letter  for  speed  to 
something  other  than  "s,"  perhaps  2  to  pick  up  "p"  as  its  hot 
letter.  Therefore,  at  the  prompt,  you  would  type  "211211". 

[10]  Raw  Scale  for  Cues  —  The  raw  scale  associated  with  each  cue 
is  determined  by  Option  10.  Thus,  Speed  is  described  in  miles  per 
hour  (mph) ,  Altitude  described  in  terms  of  feet,  etc.  These  can  be 
changed.  For  example,  earlier  we  changed  IFF  to  Emissions.  Since 
megahertz  (Mhz)  is  not  a  scale  in  which  Emissions  is  measured,  this 
will  need  to  be  changed.  The  number  of  letter  available  for  a 
label  is  limited  to  8. 

To  change  the  raw  scale  values  type  in  "10"  and  then  hit  RETURN. 
You  will  be  presented  with  the  screen  shown  in  Exhibit  18a.  This 
screen  tells  you  the  old  scale  value,  and  then  asks  you  to  enter 
the  new  scale  value.  In  our  running  example,  since  you  do  not  wish 
to  change  the  scaling  associated  with  Speed,  you  would  type  in 
"mph."  After  this  hit  RETURN,  and  repeat  this  for  all  the  scales 
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you  do  not  wish  to  change.  When  you  come  to  IFF,  whose  scale  you 
do  wish  to  change,  the  screen  will  appear  as  shown  in  Exhibit  18b. 
Now,  after  being  presented  with  the  old  scale  (Mhz) ,  you  would 
enter  the  new  scale  you  wish  to  use.  So  for  example,  if  you  wanted 
to  measure  "Emissions”  in  terms  of  temperature,  you  would  type  in 
"C"  to  reflect  degrees  Centigrade.  Continue  this  process  until  all 
attributes  have  their  scales  redefined.  .When  all  of  these  are 
entered,  you  will  automatically  go  back  to  the  Measures  Screen  that 
displays  weights  and  values. 


Insert  Exhibits  18a  and  18b  here 


[11]  Raw  Value  Ranges  —  This  portion  of  the  TEAMSET  screen 
determines  both  the  range  of  raw  score  values  associated  with  each 
attribute  and  the  manner  in  which  raw  scale  values  are  converted 
into  cue  values.  In  the  initial  version  of  the  simulation,  for 
example,  with  the  Attribute  "Speed,"  this  table  shows  that  the 
slowest  speed  is  100  mph  and  the  fastest  is  800  mph.  The  table 
also  shows  how  raw  score  ranges  convert  into  cue  values.  So  for 
example,  in  this  table,  a  speed  of  100  to  300  converts  to  a  cue 
value  of  0  (i.e.,  "non-threatening").  A  speed  of  301  to  550 
converts  to  a  cue  value  of  1  (i.e.,  "somewhat  threatening").  A 
speed  of  551  to  800  converts  to  a  cue  value  of  2  ("very 
threatening") . 

If  one  wanted  to  change  these,  it  can  be  accomplished  by  typing 
"11,"  and  then  hitting  RETURN.  The  program  will  then  ask  you  for 
the  number  of  the  attribute  that  you  wish  to  change.  So,  in  our 
example,  after  adding  Emissions  as  measured  in  degrees  centigrade, 
the  old  scale  ranges  (.2  to  1.6)  available  for  this  new  variable 
are  no  longer  appropriate.  Therefore,  we  would  type  "5"  and  then 
hit  RETURN.  You  will  be  presented  with  a  screen  that  looks  like 
that  depicted  in  Exhibit  19.  You  will  be  prompted  with  the  old  raw 
score  value  of  the  "non-threatening"  endpoint  of  the  cue  value 
continuum.  In  our  example,  this  would  be  .2  (i.e.,  the  lowest 
value  when  the  attribute  was  expressed  in  Mhz) .  At  this  point, 
type  in  the  temperature  that  will  be  the  low  end  (in  terms  of 
threat) ,  such  as  500  and  then  hit  RETURN.  The  program  now  reads 
500  degrees  centigrade  as  the  lowest  possible  temperature  for 
"Emissions. " 


Insert  Exhibit  19  here 


You  would  then  enter  the  other  end  of  the  "non-threatening"  value 
on  temperature.  So  for  example,  if  we  wanted  temperatures  of  751 
to  become  "somewhat  threatening,"  we  would  type  "750,"  and  then  hit 
RETURN,  to  indicate  that  temperature  moves  from  "non-threatening" 
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to  "somewhat  threatening"  as  one  moves  from  750  to  751  degrees 
centigrade.  You  now  enter  "751"  and  hit  RETURN,  to  make  751 
degrees  centigrade  as  the  low  point  value  for  the  "somewhat 
threatening"  range.  Continue  this  procedure  until  you  have  entered 
all  the  inflection  points  for  the  three  levels  of  threat. 

It  should  be  stressed,  that  when  "grey  zones"  are  created,  they  are 
created  via  instructions  to  participants,  not  the  program.  That 
is,  instructions  to  participants  may  say  that  500C  to  700C  is  "non¬ 
threatening,"  and  that  800C  to  1,000C  is  "somewhat  threatening." 
This  creates  a  grey  zone  for  participants  in  the  701  to  799  range. 
No  such  ambiguity  can  exist  for  the  program.  You  need  not  put  the 
inflection  point  for  the  cue  in  the  center  of  the  grey  zone. 
Instructions  to  participants  could  state  that  500C  to  750C  is  non¬ 
threatening.  This  implies  that  751C  to  800C  is  a  grey  zone.  In 
reality,  however,  all  values  that  fall  in  the  grey  zone  reflect  cue 
values  that  are  in  fact  "somewhat  threatening." 

[12]  Interaction  Weights  —  The  initial  version  of  the  TIDE^ 
simulation  contains  four  interactions  or  combination  rules,  and 
this  is  the  maximum  number  allowed.  Each  of  these  interactions,  as 
is  apparent  from  Equation  2,  was  weighted  1.  The  weight  attributed 
to  the  interactions  among  cues  can  be  modified  by  Option  12.  For 
example,  if  the  experimenter  wanted  only  one  interaction  present, 
but  wanted  to  make  that  critical,  he  or  she  could  type  in  "12,"  and 
then  hit  RETURN.  Then  enter  "2000"  which  means  that  the  first 
interaction  is  given  a  weight  of  2,  and  that  there  are  no 
interactions  other  than  this. 

[13]  NxNxNxNxN  (Interaction  Components)  —  Option  13  allows  the 
experimenter  to  define  which  two  or  more  cues  he  or  she  would  like 
to  combine  in  an  interactive  fashion.  Sticking  with  our  running 
example,  rather  than  Speed  and  Direction  going  together,  the 
experimenter  may  wish  to  have  Speed  and  Altitude  go  together,  so 
that  low  targets  that  are  flying  fast  are  especially  threatening. 
To  do  this,  type  in  "13"  and  then  hit  RETURN.  Type  in  "12"  and 
then  hit  RETURN  to  indicate  that  you  want  the  first  two  cues  to 
interact.  (Option  12  was  already  used  to  give  this  interaction  a 
weight  of  2)  .  The  other  interactions  are  given  weights  of  0,  so 
these  in  effect  are  inoperable,  although  the  experimenter  could 
erase  these  if  that  was  desired.  This  makes  the  new  linear 
combination  for  generating  the  "true  score"  associated  with  our 
running  example: 

[5]  Y  *  (1)X,  +  (1)X2  +  (DXj  +  (1)X4  +  (1)X5  +  (1)X4  +  (2)X,X2 

TIDE^  can  support  triple,  quadruple  and  quintuple  interactions. 
These  can  be  used  for  generating  what  are  basically  stochastic 
elements  to  the  equation.  This  stochastic  element  will  appear  to 
participants  as  "noise." 
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This  completes  the  discussion  of  the  "Measures  Screen"  of  the 
"modify  weights  and  values"  option  in  TEAMSET.  Many  other  changes 
can  be  introduced  in  the  "Communications  Screen."  To  get  to  the 
Communications  Screen  from  the  Measures  Screen,  type  "B"  and  hit 
RETURN. 

The  Communications  Screen.  The  Communications  Screen  contains 
Options  numbered  14  through  26,  and  this  screen  is  depicted  in 
Exhibit  16b. 

[14]  Role  Name  —  Although  unlabeled.  Option  14  deals  with  the 
names  of  the  positions  that  make  up  the  stations  in  TIDE^.  If  the 
experimenter  wanted  to  have  all  four  stations  at  sea,  and  eliminate 
the  CAD  station,  he  or  she  would  type  in  ”14"  and  then  hit  RETURN. 
You  will  be  prompted  with  the  old  names  of  the  stations  and  then 
asked  to  enter  the  new  names.  When  presented  with  CAD  relabel  this 
role  as  "Submarine."  After  all  four  names  have  been  entered,  hit 
RETURN,  and  you  will  be  returned  to  Communications  Screen. 

[15]  Who  Measures  What  —  In  the  initial  version  of  TIDE^  each  of 
the  outlying  stations  (i.e.,  CAD,  AWACs,  and  Cruiser)  can  measure 
5  attributes  and  the  carrier  can  measure  3.  Option  15  determines 
which  attributes  the  person  in  each  position  can  measure.  If  we 
wanted  to  construct  a  simulation  where  every  player  could  measure 
every  attribute,  we  could  do  this  employing  this  option.  To  do 
this,  type  "15,"  and  hit  RETURN.  You  will  be  prompted  with  the 
role  name  and  a  list  of  the  attributes  that  this  role  can  currently 
measure.  In  our  running  example,  we  have  six  cues  for  each 
station,  so  type  in  "123456"  and  then  hit  RETURN.  After  you  do 
this  for  the  last  station,  you  will  be  returned  to  the 
Communications  Screen.  In  our  running  example,  we  have  a  six  cue 
system.  If  we  want  to  make  it  so  that  each  position  can  measure 
every  attribute,  we  would  type  in  "123456"  under  15. 

[16]  Name  of  Judgments  —  Earlier  we  noted  that  there  are  eight 
possible  judgments  that  can  be  accommodated  by  TIDE^.  Option  16 
allows  one  to  change  the  name  associated  with  these  judgments.  So 
for  example,  in  an  earlier  example  of  changing  Option  3,  we  showed 
how  to  go  from  a  eight  judgment  system,  to  a  dichotomous  decision. 
At  this  point  in  TEAMSET  we  would  need  to  relabel  these  two 
options.  For  example,  we  may  relabel  them  "Standby"  and  "Fire." 
To  do  this,  type  in  "16"  and  then  hit  RETURN.  You  will  be  prompted 
with  the  old  name  for  the  first  decision  (Ignore) ,  and  will  then 
change  this  by  entering  "Standby,"  and  then  RETURN.  You  will  then 
be  prompted  with  the  old  name  for  the  second  decision  (Review) , 
which  you  would  then  change  to  "Fire." 

[17]  Values  for  Criterion  —  Exhibit  6  showed  how  scores  on  the 
linear  combination  that  aggregated  the  cue  values  was  converted 
into  the  eight  possible  criterion  judgments.  Option  17  is  used  to 
set  the  cut-offs  for  these  criteria.  For  example,  in  the  default 
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version  of  the  simulation,  0-2  is  an  “Ignore, •'  3-5  is  a  "Review," 
etc.  In  our  running  example,  we  have  turned  the  decision  into  a 
dichotomy,  and  changed  the  linear  combination  from  that  shown  in 
Equation  3  with  that  now  shown  in  Equation  5.  We  might  draw  the 
cut-offs  of  a  "Standby"  from  0  to  10,  and  the  cut-off  for  a  "Fire" 
from  11  to  20. 

[18]  Names  of  Outcomes  —  Option  18  allows  the  experimenter  to 
change  the  niimber  of  outcomes  associated  with  any  decision  — 
criterion  combination.  In  the  initial  version  of  TIDE^,  there  are 
five  possible  outcomes.  This  is  the  maximum  allowed.  This  nvimber 
can  be  reduced,  however.  In  our  running  example,  where  we  have 
reduced  the  criterion  and  judgment  to  a  dichotomy,  we  may  simply 
label  the  outcomes  "Hit"  and  "Miss".  To  do  this,  type  in  "18"  and 
then  hit  RETURN.  You  will  be  prompted  with  the  old  outcome  names, 
and  you  should  replace  these  with  the  new  names  in  the  same  manner 
as  was  done  with  attribute  names,  scale  ranges,  and  so  on. 


[19]  Judgment  Hot  Keys  —  Just  as  one  can  identify  hot  keys  for 
measuring  attributes,  querying  attributes  or  transmitting  data,  one 
can  also  use  hot  keys  to  register  judgments.  These  are  specified  in 
a  manner  identical  to  that  previously  discussed  for  Option  9. 

[20]  Feedback  Type  —  As  mentioned  earlier  there  are  three  options 
for  providing  feedback  in  TIDE^,  immediate,  delayed  and  summarized. 
Option  20  allows  you  to  choose  which  of  these  forms  you  would  like. 
The  default  form  of  feedback  is  immediate  "F".  If  you  want  to 
delay  the  feedback  so  that  participants  get  feedback  from  Trial  1, 
three  trials  later,  you  would  type  "20"  and  then  hit  RETURN.  Type 
in  "D"  and  then  hit  RETURN  again.  This  turns  ou  the  delayed 
feedback  version  of  the  simulation.  To  determine  the  length  of  the 
delay  you  would  need  to  employ  Option  [21]  which  is  discussed  next. 
If  you  wanted  to  provide  summarized  feedback  after  three  trials, 
you  would  follow  the  same  steps,  except,  choose  "S"  rather  than 
"D" . 

[21]  Number  of  Trials  Delayed/Summarized  —  If  one  opts  to  use 
delayed  or  summarized  feedback  in  Option  [20],  one  should  then  use 
Option  [21]  to  specify  the  number  of  trials  that  feedback  will  be 
delayed  or  summarized  across.  In  our  running  example,  we  wish  to 
delay  feedback  three  trials,  so  that  feedback  on  Trial  1  is 
presented  after  Trial  4,  Trial  2  after  Trial  5,  and  so  on.  The 
same  procedure  would  be  used  to  summarize  feedback  after  every 
three  trials.  So  for  example,  if  the  experimenter  wanted  to  provide 
participants  with  summarized  feedback  after  every  three  trials,  he 
or  she  would  type  "21",  and  then  hit  RETURN.  Type  "3"  and  then  hit 
RETURN,  and  now  feedback  will  be  summarized  rather  than  delayed. 

[22]  Feedback  Access  —  In  the  default  version  of  the  simulation, 
each  team  member  gets  detailed  feedback  for  the  team  between 
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trials.  Since  the  Carrier  registers  the  team's  decision,  this  is 
the  Carrier's  individual  feedback  as  well.  Non-carriers  get  no 
such  detailed  feedback  regarding  their  recommendations  in  the 
default  version  of  the  simulation.  However,  this  can  be  changed. 


There  are  basically  five  different  decisions  to  be  made  for  each 
team  member  when  it  comes  to  configuring  feedback.  These  five 
decisions  are: 


(1) 

Will  the  person  have  access 
Carrier  ( i . e . ,  the  team) ? 

to 

feedback 

for 

the 

(2) 

Will  the  person 
CAD? 

have 

access 

to 

feedback 

for 

the 

(3) 

Will  the  person 
AWACs? 

have 

access 

to 

feedback 

for 

the 

(4) 

Will  the  person 
Cruiser? 

have 

access 

to 

feedback 

for 

the 

(5) 

Will  the  person 
four  positions  s: 

have 

access 

to 

feedback 

for 

all 

Lmultaneously 

on 

a  single 

screen? 

These  decisions  are  registered  by  entering  either  "Y"  for  yes  or 
"N"  for  No,  in  answer  to  each  of  the  questions  numbered  (1)  through 
(5)  above  for  each  of  four  players.  That  is,  every  time  one  wishes 
to  change  feedback  access,  one  must  register  20  decisions  (five 
questions  for  four  team  members) . 

Refer  to  Exhibit  20  to  see  how  the  answers  to  these  questions  are 
registered  in  TIDE^.  One  registers  these  decisions  by  inserting  a 
Y  or  N  above  the  pair  of  vertical  numbers  that  identify  the 
question  and  the  team  member  for  whom  the  question  is  being 
answered.  The  structure  is  made  up  of  3  rows  and  20  columns.  The 
first  row  is  where  one  enters  the  answer  to  the  5  questions  posed 
above.  The  second  row  specifies  the  terminal  for  which  the 
question  is  being  answered.  The  third  row  specifies  whose  feedback 
will  or  will  not  be  made  available. 


Insert  Exhibit  20  here 


So  for  example,  assume  that  we  would  like  to  generate  a  simulation 
where  the  Carrier  can  get  individual  feedback  on  every  team 
member's  performance,  but  that  the  other  team  members  can  only  get 
feedback  on  their  own  individual  performance  and  the  team's 
performance.  To  accomplish  this,  type  in  "22"  and  then  hit  RETURN. 
The  cursor  will  move  up  to  the  "View  Feedback"  line,  two  spaces 
left  of  the  colon.  To  make  it  so  the  Carrier  can  have  access  to 
all  feedback,  we  need  to  answer  questions  (1)  through  (5)  above 
"yes"  for  the  Carrier.  Therefore,  we  would  type  in  "yyyyy»»  as  the 
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first  five  entries.  Since  we  want  the  CAD  (i.e.,  the  second 
position)  to  get  feedback  on  his  or  her  own  and  the  team,  we  would 
then  type  in  "YYNNN"  to  indicate  that  CAD  can  access  feedback  on 
the  Carrier  (i.e.,  the  team)  and  himself  or  herself.  For  the 
AWACS,  we  would  answer  the  five  questions  "YNYNN”,  and  for  the 
Cruiser,  we  would  answer  the  questions  "YNNYN."  Thus,  the  entire 
line,  which  represents  the  answers  to  the  20  questions,  would  read: 

YYYYYYYNNNYNYNNYNNYN 

For  team  members  engaged  in  the  simulation  to  evoke  these  options 
they  need  to  hit  certain  function  keys.  F4  provides  Carrier 
feedback,  F5  provides  access  to  CAD  feedback,  F6  provides  access  to 
AWACs  feedback,  F7  provides  access  to  Cruiser  feedback,  and  F8 
provides  access  to  all  four  simultaneously  on  one  screen.  If  a 
team  member  does  not  have  access  to  a  specific  feedback  source, 
then  hitting  the  function  key  associated  with  that  source  will  have 
no  effect.  The  instructions  about  the  feedback  must  be  provided  by 
the  experimenter  to  the  participants.  There  is  no  menu  driven 
source  for  participants  to  access  feedback. 

[23]  Who  Can  Query  Whom  —  Communication  channels  in  the  default 
version  of  TIDE^  are  set  up  so  that  each  player  can  query, 
transmit,  send  and  receive  text  from  every  other  player.  This  can 
be  changed.  Option  [23]  controls  the  query  function,  and 
determines  who  can  query  whom.  Exhibit  21  shows  an  expanded  view 
of  this  section  of  the  Communications  Screen  with  descriptions  of 
functions  inserted.  The  top  line  of  this  screen  contains  the 
numbers  1111222233334444  where  1  refers  to  the  Carrier,  2  the  CAD, 
3  the  AWACs  and  4  the  Cruiser.  This  lin<»  indicates  the  source  of 
the  query  (that  is  where  it  originates) .  Just  below  this  line  is 
another  line  that  contains  the  numbers  2341  3412  4123  where  the 
numbers  refer  to  the  team  members  in  the  same  manner  described 
previously.  This  line  indicates  the  destination  of  the  query.  The 
top  line,  and  the  line  below  it  form  vertical  pairs.  The  vertical 
pairs  set  up  the  question  "can  x  query  y,"  where  x  refers  to  the 
source  (on  the  top  line)  and  y  the  destination  (the  bottom  line) . 
Thus,  the  first  vertical  pair  is  12  and  therefore  asks  can  the 
Carrier  (i.e..  Position  1)  query  the  CAD  (Position  2).  The  rest  of 
the  pairs  complete  all  possible  alternatives  for  query  sources- 
destinations.  The  blanks  in  the  second  line  are  there  to  reflect 
the  fact  that  a  team  member  cannot  query  himself  or  herself. 


Insert  Exhibit  21  here 


Just  below  the  "From;"  and  "To:"  lines  is  a  string  of  Y's  or  N's 
that  provide  the  answer  to  the  question  set  by  the  vertical  pair 
above  it.  Thus,  a  "Y"  below  the  first  vertical  pair,  12,  means 
that  the  Carrier  can  send  a  query  to  the  CAD.  In  fact,  as  we  said 
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already,  in  the  default  version,  everyone  can  query  everyone  else, 
so  all  the  entries  in  this  line  are  Y  by  default.  A  vertical  pair 
that  contains  a  blank  (i.e.,  the  vertical  pair  that  asks  can  x 
query  x,  a  meaningless  question)  will  always  have  a  Y  below  it  and 
this  cannot  be  changed. 

Let '  s  assime  that  we  wanted  to  restrict  queries  and  set  up  a 
"wheel,"  network,  where  the  Carrier  can  query  everyone,  but  the 
other  stations  could  only  query  the  Carrier.  To  do  this,  type  in 
"23"  and  then  hit  RETUKN.  The  cursor  will  move  up  to  the  line 
labeled  "Query  to:"  in  the  Communications  Screen  (the  right  of 

[23]).  At  this  point  you  would  enter:  YYYYYNNNYNNNYNNN 


[24]  Who  Can  Transmit  Raw  Values  to  Whom  —  Option  [24]  follows  the 
exact  same  format  as  Option  [23],  except  in  this  case,  the  question 
posed  by  the  vertical  pair  is  "can  x  send  a  transmission  to  y?" 
Changes  are  made  in  the  same  manner  described  in  [23],  and  thus  if 
we  wanted  to  extend  our  wheel  network  to  transmissions  we  would 
type  "24",  then  hit  RETURN,  and  then  enter:  YYYYYNNNYNNNYNNN. 

[25]  Who  Can  Send  Text  Messages  to  Whom  —  This  option  follows  the 
exact  same  format  as  [23]  and  [24]  but  now  a  vertical  pair  sets  up 
the  question,  "can  x  send  a  text  message  to  y?"  Changes  are  made 
here  the  same  way  as  described  above.  Thus,  to  convert  the  default 
communication  network  to  a  wheel,  one  would  type  in  "25",  then  hit 
RETURN,  ard  then  enter:  YYYYYNNNYNNNYNNN. 

[26]  Writing  to  Personal  Logs  —  Recall  that  team  members  have  the 
option  of  saving  any  text  message  sent  to  them  from  another  player 
by  using  the  log  option  that  comes  up  after  receipt  of  a  text 
message.  You  can  use  Option  [26]  to  allow  players  to  send  text 
messages  to  themselves.  Thus,  the  log  can  become  a  personal 
notebook  for  the  player  where  he  or  she  can  store  information  on 
roles,  rules  or  characteristics  of  other  players.  This  option  takes 
the  place  of  giving  participants  paper  to  keep  notes  on,  and  has 
the  advantage  over  paper  in  that  the  timing  and  content  of  the 
notes  are  captured  by  the  simulation  program. 

The  initial  version  allows  personal  logs,  but  this  can  be  turned 
off.  For  example,  if  we  wanted  to  make  it  so  that  the  Carrier 
could  keep  a  log,  but  the  other  players  could  not,  we  would  type  in 
"26"  and  then  hit  RETURN.  The  cursor  will  move  up  to  the  line 
labeled  "Tm  To  Log:"  (i.e..  Option  [26]).  At  this  point,  you 
would  type  "YNNN". 

There  is  one  last  aspect  of  the  simulation  that  can  be  changed  with 
TEAMSET,  and  this  deals  with  the  icons.  The  icons  have  their  own 
screen.  To  get  to  the  Icon  Screen  from  either  the  Measures  Screen 
or  the  Communication  Screen,  type  "I"  and  then  hit  RETURN. 
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The  Icon  Screen.  By  this  tine  you  may  have  noted  the 
rudimentary  form  of  the  icons  that  come  with  TIDE^.  Because  menus 
have  to  be  pulled  down  on  top  of  Icons,  the  program  will  not  allow 
screen  space  to  be  sectioned  off  for  sophisticated  graphics. 
Despite  this,  experimenters  who  wish  to  do  so  can  substitute  their 
own  rudimentary  icons  for  those  provided. 

To  make  this  kind  of  change  by  first  typing  ''I”  and  hitting  RETURN. 
This  will  call  up  the  third  screen  under  "modify  weights  and 
values"  option  of  TEAMSET.  This  screen  shows  you  the  icons  that 
are  currently  being  used  by  the  simulation.  In  the  default  version 
of  the  simulation  they  are  the  Carrier  (position  1) ,  CAD  (position 
2),  AWAC  (position  3)  and  Cruiser  (position  4).  Inside  each  icon 
is  the  label  associated  with  the  icon. 

To  change  an  icon,  (i.e.,  change  the  CAD  to  a  Submarine) ,  you  would 
type  "2W",  and  the  hit  RETURN.  The  2  selects  the  CAD  icon  and  the 
"W"  clears  the  old  icon  so  that  a  new  one  can  be  created.  The 
number  pad  on  the  keyboard  is  used  to  draw  the  new  icon.  The  four 
directional  arrows  will  create  a  line  one  space  in  length  in  the 
direction  of  the  arrow.  To  make  comers  you  would  use  the 
following  keys: 

end  key  makes  a  lower  left  comer, 
home  key  makes  an  upper  left  corner, 

PgDn  key  makes  a  lower  right  corner, 

PgUp  key  makes  an  upper  right  corner. 

It  should  be  noted  that  this  is  not  a  simple  task  at  first  but  in 
time  icon  drawing  can  be  mastered. 

If  you  wanted  to  move  the  Submarine  icon  down  the  screen  a  little 
you  would  type  "2D"  and  then  hit  RETURN.  This  will  move  the  icon 
down  one  space.  If  you  want  the  Submarine  lower  you  would  continue 
to  type  "2D"  until  the  icon  is  where  you  want  it.  It  is  important 
to  note  at  this  time  that  you  have  to  use  CAPITAL  t.rttrrs  to  move 
the  icons.  Lower  case  letters  move  the  icon  label  as  will  be 
explained  next.  To  move  the  icons  you  use  the  following  letters 
with  the  appropriate  icon  number: 

D  moves  the  icon  down  one  space, 

U  moves  the  icon  up  one  space, 

L  moves  the  icon  to  the  left  one  space, 

R  move  the  icon  to  the  right  one  space. 

After  the  icon  is  moved  to  it  new  place  you  will  need  to  move  the 
icon  label.  To  move  the  Submarine  label  down  you  would  type  "2d" 
and  this  would  move  the  label  down  one  space.  Note  that  to  move 
the  icon  labels  you  use  lower  case  letters.  The  same  letters 
result  in  the  same  moves  they  did  when  moving  the  icon. 
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For  example,  assume  we  eliminated  the  CAD  station  in  our  running 
example,  and  replaced  it  with  a  submarine.  A  rudimentary  icon  for 
a  submarine  could  be  developed  and  added  to  the  screen  so  that  when 
completed,  the  new  sea  screen  would  look  like  that  shown  in  Exhibit 
22. 


Insert  Exhibit  22  here 


To  save  the  changes  made  in  this  session,  type  "W  and  hit  RETURN 
to  execute  the  modifications.  The  new  simulation  looks  like  that 
displayed  in  Exhibit  23,  and  can  be  contrasted  with  that  displayed 
in  Exhibit  11,  which  is  the  initial  version  of  the  simulation.  If 
we  did  not  wish  to  save  the  changes,  type  "C"  to  cancel  them. 


Insert  Exhibit  23  here 


Establishing  Context  Effects  with  Task  Changes 

There  are  many  different  context  effects  of  interest  to  researchers 
in  the  area  of  teams  and  decision  making  that  can  be  manipulated  by 
changes  in  the  task.  We  give  several  examples  of  these  below, 
along  with  the  corresponding  number  in  TEAMSET  (shown  within 
brackets)  that  was  described  above. 

Task  Complexity.  Earlier  we  discussed.  Wood's  (1986)  three 
primary  dimensions  of  task  complexity:  component  complexity, 
coordinative  complexity,  and  dynamic  complexity.  We  also  showed 
how  the  first  two  of  these  can  be  manipulated  with  TEAMSET  by 
creating  targets  that  are  yoked  on  the  attributes  that  form  the 
combination  rules.  These  two  type  of  complexity  can  also  be 
manipulated  by  changing  parameters  in  the  "Modify  Weights  and 
Values"  section  of  TEAMSET. 

Again,  component  complexity  refers  to  the  number  of  pieces  of 
information  that  have  to  be  processed  to  perform  the  task.  This  is 
readily  manipulated  in  TIDE^  by  simply  altering  the  number  of 
attributes  that  can  be  measured  (see  [1]  above).  The  coordinative 
aspect  of  task  complexity  can  also  be  handled  by  setting  all  the 
interactions  to  zero  (see  [12]  above).  Placing  large  weights  on 
the  interactions,  and  raising  the  order  of  these  (creating  three  or 
four  way  interactions  -  see  [13]  above)  will  have  just  the  opposite 
effect  on  coordinative  complexity. 

There  is  no  necessity  that  an  attribute  that  can  be  measured  have 
any  ecological  validity  with  respect  to  predicting  the  criterion. 
For  example,  one  could  create  a  nine  attribute  system  where  three 
of  the  attributes  are  weighted  0  (see  [7]  or  [12]  above)  and 
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therefore  simply  create  noise  on  the  predictor  side.  The  inclusion 
of  fifth  order  interaction  terms  also  have  the  psychological  effect 
of  adding  noise  to  the  criterion  side  (see  [13]  above). 

Recmired  Interdependence.  The  initial  version  of  TIDE^  uses 
combination  rules,  and  then  nests  dimensions  within  roles  such  that 
no  one  role  can  get  all  the  information  on  any  combination  rule. 
This  forces  interdependence  among  players.  Interdependence  can  be 
manipulated,  however,  by  adjusting  who  can  measure  what  (see  [15]) . 
High  redundancy,  where  many  roles  can  measure  all  the  same 
attributes,  leads  to  low  interdependence.  Taken  to  an  extreme, 
this  could  mean  that  all  players  can  measure  all  attributes  by 
themselves.  Low  redundancy,  on  the  other  hand,  means  everyone 
measures  unique  attributes,  and  this  creates  high  interdependence. 
Taken  to  an  extreme,  one  could  employ  an  eight  attribute  system 
where  each  of  four  roles  can  measure  two  unique  attributes. 

Base  Rate  for  Ambiguous  Targets.  Earlier  we  noted  that 
through  the  use  of  "grey  zones”  presented  in  the  instructions,  one 
can  create  targets  that  are  ambiguous  to  participants.  In  the 
initial  version  of  TIDE^  the  so  called  "grey  zones"  are  in  reality 
demarcated  so  that  values  in  the  lower  half  of  the  range  fall  on 
one  side  of  the  cut-off.  For  example,  the  grey  zone  on  speed  runs 
from  275  -  325  mph,  but  in  reality,  a  speed  of  300  mph  is  non¬ 
threatening  whereas  301  is  somewhat  threatening.  One  can  create 
"biased"  grey  zones,  however,  where  almost  all  values  within  the 
"grey  zone"  fall  one  way  or  the  other.  Thus,  with  speed,  the  grey 
zone  of  275  -  325,  could,  in  reality,  relate  to  a  system  where  275 
is  non-threatening,  but  276  through  325  is  somewhat  threatening. 
Thus,  when  in  doubt,  participants  in  this  kind  of  context  should 
lean  toward  aggressive  responses.  Of  course,  a  biased  grey  zone  of 
just  the  opposite  nature  could  also  be  created. 

Rectuired  Precision.  The  initial  version  of  TIDE^  uses  seven 
judgment  categories  and  allows  for  the  possibility  of  five 
different  outcomes.  This  could  be  considered  a  precise  decision 
making  context.  The  system  we  replaced  it  with,  however,  requires 
much  less  precision  (see  [3]  and  [4]  above).  It  has  only  two  types 
of  judgments  (Standby  and  Fire) ,  and  two  types  of  outcomes  (Hit  or 
Miss) .  One  may  wish  to  require  less  precise  decisions  in  highly 
speeded  contexts,  where  there  might  be  one  or  two  decisions  made  a 
minute.  In  this  context,  the  number  of  trials  for  a  team  within  a 
specified  time  period  could  be  increased  relative  to  the  nvimber 
that  might  be  possible  for  teams  making  more  finely  graded 
judgments. 

Group  Size.  The  initial  version  of  TIDE^  uses  four  players, 
but  this  number  can  be  reduced  to  triads  and  dyads  (see  [5]  and 
[14]  above).  It  can  even  be  reduced  to  one,  however  we  will 
discuss  single  person  versions  of  TIDE^  in  detail  in  a  later 
section. 


TIDE^ 

49 

CoTorounication  Networks.  Many  of  the  conventional 
communication  networks  studied  in  the  groups  literature,  such  as 
"wheels,"  "lines,"  "circles,"  "comcons,"  etc.  can  be  invoked  in 
TIDE^.  These  can  be  created  by  manipulating  the  options  on  who  can 
query,  transmit,  or  send  text  messages  to  whom  (see  [22],  [24], 
[25] ,  and  [26]) . 

Speed  of  Communications.  Communications  in  the  initial 
version  of  TIDE^  move  relatively  quickly  and  efficiently  between 
players,  with  a  maximum  transmission  time  of  3  seconds. 
Communications  can  be  made  much  slower,  and  therefore  become  more 
costly  and  less  helpful  to  players  by  manipulations  of  the  "Message 
wait  time"  (see  [#6]  above). 

Feedback  Variations.  In  the  initial  version  of  TIDE^  the  team 
receives  feedback  of  team  performance  and  the  performance  history 
for  the  team  is  displayed.  Individuals  get  to  see  their  respective 
decisions  but  are  not  given  specific  feedback  on  their  performance, 
nor  are  their  personal  performance  histories  presented  with  the 
feedback  screen.  These  can  be  made  available  to  participants  by 
manipulating  Option  [22]. 

In  addition,  the  initial  version  of  TIDE^  gives  feedback 
immediately  with  respect  to  the  target  that  the  players  just 
encountered.  Feedback  on  targets  can  be  delivered  in  two  other 
ways,  however.  First,  one  can  obtain  trial-delayed  feedback,  where 
the  feedback  coming  up  on  the  screen  actually  refers  to  a  target 
experienced  a  specified  niunber  of  trials  prior  to  the  target  just 
encountered.  In  other  words,  participants  act  on  a  target  at  Time 
1,  but  do  not  receive  feedback  until  Time  4,  after  acting  on 
perhaps  three  other  targets  in  the  meantime.  This  can  be 
accomplished  as  described  above  in  Option  [20]  and  [21]. 

Second,  feedback  can  also  be  summative  over  many  trials  rather  than 
provided  after  every  single  trial.  That  is,  participants  could  act 
on  five  targets  in  a  row  before  receiving  any  feedback.  Then,  the 
feedback  they  do  receive  would  just  be  for  the  five  targets  as  a 


whole  (e.g.,  three  hits,  a  near  miss  and  a  miss),  with  no  way  of 
tying  specific  decisions  to  specific  outcomes.  This  can  be 
accomplished  through  Options  [20]  and  [21]. 

Finally,  the  feedback  screen  can  be  turned  off  altogether.  There 
are  two  ways  of  doing  this.  First,  as  previously  described  in  the 
"session  to  maintain"  part  of  TEAMSET,  one  can  set  the  feedback 
time  to  zero.  If  one  does  this,  then  targets  come  up  one  after 
another  with  no  break  in  between  them.  If  one  wished  to  eliminate 
feedback,  but  not  increase  tempo,  then  a  second  means  of 
eliminating  feedback  should  be  used.  Specifically,  one  could  use 
the  "modify  weights  and  values"  part  of  TEAMSET  to  delay  feedback 
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over  X  trials  where  x  equals  the  total  number  of  trials.  This 
method  allows  one  to  create  rest  periods  (where  players  get  a  blank 
orange  screen)  where  feedback  screens  used  to  appear. 

Goal  and  Projection  Variations.  The  initial  version  of  TIDE^ 
has  a  team  goal  option,  that  comes  with  a  projection  that  tells 
participants  where  they  will  be  at  the  end  of  the  trial  if  they 
continue  to  perform  at  the  same  rate  experienced  to  that  point. 
One  can  also  create  individual  goals  and  projections  for  team 
members.  This  can  be  accomplished  as  described  above  in  the 
"session  to  maintain"  part  of  TEAMSET. 


Changing  the  Scenario  with  TEAMSET 

Up  to  this  point  we  have  been  changing  the  various  aspects  of  the 
task  with  TEAMSET,  but  we  have  retained  the  scenario  of  naval  air 
patrol.  The  "Modify  weights  and  values"  portion  of  TEAMSET  allows 
much  more  radical  changes  in  the  context,  and  one  can  even  create 
different  scenarios.  For  example,  by  changing  cue  names,  cue 
values,  ranges,  player  names,  judgments  and  outcomes  entirely 
different  scenarios  can  be  developed. 

For  example,  TIDE^  could  be  turned  into  a  personnel  selection  task 
where  their  are  four  team  members;  an  interviewer,  a  testing 
specialist,  a  recruiter,  and  a  plant  manager  (the  leader) .  The 
applicant  becomes  the  "target"  that  might  be  assessed  on  eight 
dimensions;  interpersonal  skills  and  experience  (measured  by  the 
interviewer) ;  verbal  and  quantitative  ability  (measured  by  the 
testing  specialist)  ;  strength  of  academic  program  and  GPA  (measured 
by  the  recruiter) ;  fit  with  current  employees  and  fit  with  future 
organizational  strategy  (measured  by  the  plant  manager) .  These 
four  could  then  pool  their  judgments  and  come  up  with  a  team 
decision  either  graded  (the  desirability  of  hiring  the  individual) 
or  dichotomous  (hire  or  not  hire) ,  which  then  can  be  evaluated 
against  some  criterion  developed  for  the  scenario. 

TIDE^  could  also  be  turned  into  an  investment  banking  scenario 
where  the  four  players  might  be  a  CEO  (the  leader) ,  a  production 
specialist,  an  financial  specialist  and  a  marketing  specialist  that 
have  to  come  together  to  make  recommendations  about  investment 
opportunities  (e.g.,  whether  to  purchase  another  company). 
"Targets"  are  then  potential  takeover  targets  and  decisions  can  be 
based  on  measures  of:  interest  rate  projections,  capital 
availability  projections,  company  ledgers,  company  performance 
history,  company  technology,  industry  analysis,  analysis  of 
competitor  with  the  industry,  etc.  TIDE^  could  in  the  same  manner 
be  turned  into  a  medical  scenario  where  medical  specialists  like  a 
cardiologist,  an  anaesthetist,  an  admitting  emergency  physician, 
and  a  nurse  make  decisions  regarding  the  treatment  of  a  patient 
based  on  information  dealing  with  initial  onset  of  symptoms,  test 
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results,  behavioral  monitoring,  etc. 

Scenarios  described  so  far,  have  typically  involved  simulations 
where  the  criterion  was  an  invention  of  the  experimenter,  but 
studies  in  ecological  prediction  could  also  be  conducted  with 
TIDE^.  For  example,  teams  of  participants  could  be  asked  to 
handicap  horse  races.  Members  could  be  given  "live”  information 
taken  from  actual  racing  forms  and  presented  in  the  form  of  nine 
attributes  via  TIDE^.  Members  could  exchange  information  and  then 
make  predictions  about  which  horse  would  win.  These  could  then  be 
contrasted  with  real  outcomes  from  the  races.  Thus,  users  of  TIDE^ 
are  not  limited  to  hypothetical  decision  contexts  and  researchers 
can  take  advantage  of  the  many  archival  sources  available  to  come 
up  with  real  and  interesting  contexts  where  teams  might  come 
together  to  make  decisions. 


Non-Research  Uses  of  TIDE2  with  TEAMSET 

Although  TIDE^  was  designed  as  a  research  vehicle,  it  may  also  have 
certain  non-research  uses.  For  example,  it  could  be  employed  as  a 
group  development  or  team  building  exercise.  It  could  be  used  as 
a  work  simulation  for  a  group  or  an  individual  for  tasks  with  a 
large  number  of  decision-making  components.  It  could  be  used  as  an 
assessment  device,  much  like  a  "hard  wired"  Leaderless  Group 
Discussion  exercise.  It  could  also  be  used  in  individual 
assessment  as  a  perceptual  and  judgment  measure  of  personality 
characteristics  and  decision  style  (see  Nunnally,  1978;  Hollenbeck 
&  Whitsjner,  1988)  . 


De-Grouping  TIDE^ 

Although  designed  as  a  team  simulation,  TIDE^  can  also  be  used  as 
an  individual  task  where  there  is  a  single  person  making  decisions. 
This  would  be  useful  for  comparing  teams  versus  individuals  on  the 
same  task,  or  for  strict  individually-oriented  decision-making 
research  that  used  no  teams  at  all.  There  are  two  means  of 
eliminating  the  team  aspect  of  TIDE^. 

One  Player  -  One  Role.  The  TEAMSET  program  allows  the 
researcher  to  change  many  of  the  parameters  associated  with  the 
simulation,  and  this  program  can  be  used  to  convert  TIDE^  into  an 
individual  task. 

The  researcher  simply  needs  to  specify  that  the  team  will  have  only 
one  member  (see  [5]  and  [14]  in  the  "modify  weights  and  values 
program) ,  and  set  up  the  "who  can  measure  what"  parameter  (see 
[15])  so  that  the  one  person  can  measure  all  attributes.  If  the 
computers  are  shut  off  the  network,  the  four  computers  used  to  run 
one  team  can  be  used  to  run  four  individual  decision  makers 
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simultaneously. 

Hollenbeck,  Sego,  Ilgen  and  Major  (1991)  compared  the  effectiveness 
of  teams  versus  individuals  on  the  initial  version  of  TIDE^.  The 
reader  is  referred  to  that  manuscript  for  the  results  of  that 
comparison. 

One  Player  -  Multiple  Roles.  The  TEAMSET  program  also  allows 
one  to  run  an  individually-oriented  version  of  the  simulation, 
where  there  are  multiple  roles.  The  One  Player-Multiple  Role 
version  differs  from  that  describe  above  in  that  the  player  can 
move  back  and  forth  from  one  role  to  another  using  the  F4  through 
F7  keys.  In  this  version  of  the  single  player  simulation,  the 
researcher  could  still  Impose  a  hierarchical  knowledge  base  where 
the  single  person  has  to  access  different  stations  to  learn 
different  things  about  the  target.  Thus,  to  get  information  on 
speed,  the  participant  would  have  to  recall  that  speed  can  only  be 
measured  by  the  AWACs,  and  then  transfer  into  that  station  using 
the  F5  key.  He  or  she  may  even  feel  the  need  to  transmit  this 
information  back  to  the  carrier  position  so  that  the  information 
will  be  available  in  the  summary  box.  Thus,  the  One  Player- 
Multiple  Role  version  of  the  individually-oriented  simulation  is 
much  more  complex  than  the  One  Player-One  Role  version. 
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Output  from  TIDE^ 

One  of  the  advantages  of  using  TIDE^  in  research  is  that  large 
amounts  of  information  are  automatically  collected  during  the 
simulation  sessions.  This  simplifies  the  transition  in  going  from 
data  collection  to  data  analysis. 

Overview  of  Output  Files 

As  an  overview,  TIDE^  can  be  used  to  produce  three  types  of  output 
files  at  the  end  of  every  session.  The  first  file  provides  a 
summary  of  several  important  objective  measures  of  group  outcomes 
and  processes.  The  second  file  provides  a  written  record  of  every 
text  message  sent  during  the  session.  This  includes  the  trial 
number,  the  source,  the  destination  and  time  of  every  message.  The 
third  file  converts  almost  every  keystroke  made  during  the  sessions 
into  a  quantitative  file  in  SPSS  format. 

The  output  data  are  stored  and  compiled  on  a  number  of  different 
files,  each  of  which  will  be  described  in  detail  below.  As  an 
overview,  each  team  produces  four  raw  data  files,  one  for  each 
station.  Before  using  TEAMSTAT  to  create  the  three  files  described 
above,  these  four  raw  data  files  need  to  be  merged  into  one  file, 
and  sorted.  The  files  are  combined  via  a  program  called  RENL0G2, 
and  they  are  sorted  via  a  program  called  TEAMSORT.  Both  RENL0G2 
and  TEAMSORT  are  run  automatically  at  the  end  of  an  experimental 
session  (i.e.,  they  do  not  need  to  be  invoked  explicitly  by  the 
experimenter) .  At  this  point,  the  file  has  the  name: 

xxxyyzzz.es 

where  xxx  refers  to  the  group  number,  yy  refers  to  the  session 
number,  and  zzz  refers  to  the  experiment  number.  CS  is  a 
designation  that  indicates  that  the  file  has  been  combined  and 
sorted.  Once  the  output  from  the  simulation  is  in  this  form, 
TEAMSTAT  can  be  used  to  generate  the  summary  file  (i.e., 
xxxyyzzz.SUM) ,  the  message  file  (i.e.,  xxxyyzzz .MSG) ,  and  the  data 
analysis  file  (i.e.,  xxxyyzzz.SPS) .  These  are  all  described  below. 


Choosing  an  Output  File  From  TEAMSTAT 

When  an  experimental  session  is  over,  an  autoexec  file 
automatically  creates  the  xxxyyzzz. CS  file.  To  create  the 
xxxyyzzz.SUM,  xxxyyzzz. MSG,  xxxyyzzz.SPS  files  you  need  to  run 
TEAMSTAT.  To  invoke  this  program  type  "TEAMSTAT”  and  hit  RETURN. 
You  will  be  prompted  with  the  screen  shown  in  Exhibit  24.  At  this 
point,  you  simply  enter  the  hot  key  associated  with  the  type  of 
file  that  you  would  like  to  create  with  TEAMSTAT  (i.e.,  .SUM,  .MSG, 
.SPS),  and  then  hit  RETURN.  Another  screen  appears  prompting  you 
for  the  input  file.  Enter  the  input  file  name  (i.e.,  xxxyyzzz. CS) 
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and  then  hit  RETURN.  A  third  screen  appears  during  processing  of 
the  data  which  confirms  which  file  is  being  created,  and  where  the 
program  is  in  the  process.  When  this  program  is  completed,  you  are 
returned  to  the  screen  shown  in  Exhibit  24. 


Insert  Exhibit  24  here 


xxxwzzz.SUM:  Objective  Measures  of  Group  Outcomes  and 
Processes .  Exhibit  25  shows  a  portion  of  the  typical  output  file 
derived  from  TEAMSTAT  program  after  generating  a  xxxyyzzz.SUM 
file.  This  file  provides  a  quick  overview  of  the  major  outcomes 
and  processes  associated  with  that  team's  experience  during  the 
experimental  session.  We  will  walk  through  each  section  of  the 
file  highlighting  the  meaning  of  the  information  provided. 


Insert  Exhibit  25  here 


At  the  top  left  portion  of  the  screen,  one  can  see  the  number  of 
the  trial  that  is  being  summarized.  So  in  Exhibit  25,  we  see 
summaries  for  specific  Trials  #18  and  #19,  as  well  as  one  total 
summary  for  all  19  games  that  made  up  that  experimental  session. 

Let's  first  examine  the  output  associated  with  the  18th  trial,  that 
is  printed  on  the  top  portion  of  the  exhibit.  Just  under  the  Trial 
number,  information  is  provided  on  how  much  time  the  team  had 
during  that  trial,  in  this  case,  210  seconds.  Just  under  this  is 
the  "Correct  Decision"  for  the  target,  which  in  this  case  was  1, 
which  stands  for  Ignore  (2  is  Review,  3  is  Monitor,  etc.).  Just  to 
the  right  of  this  is  the  team's  outcome  associated  with  this 
target,  which  happened  to  be  a  Near  Miss. 

In  the  next  section  of  the  screen,  information  is  provided  for  each 
of  the  four  team  members.  This  information  is  arrayed  in  four 
major  columns,  each  of  which  has  several  sub-columns.  The  major 
columns  are  for  the  Carrier,  CAD,  AWACs  and  Cruiser  roles. 

Looking  first  at  the  Carrier,  one  sees  that  his  or  her  judgment 
(which  is  the  Team's  official  judgment)  was  a  "2"  (i.e.,  a  Review). 
Since  we  know  already  that  the  "Correct  Decision"  for  this  target 
was  a  "1"  (i.e.,  an  Ignore)  we  see  that  the  team  was  1  point  off  in 
their  judgment,  which  is  why  the  outcome  was  a  NEAR  MISS.  Just 
below  the  judgment  line,  we  can  also  see  the  time  at  which  this 
judgment  was  rendered  —  205  seconds.  Since  we  know  already  that 
there  was  210  seconds  in  the  total  trial,  this  means  that  the 
Carrier  rendered  its  decision  with  only  five  seconds  remaining  in 
the  trial. 
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Moving  across  the  colvinns,  we  see  the  same  types  of  information 
arrayed  for  the  other  three  team  members.  The  CAD,  for  example, 
also  made  a  Review  judgment,  but  the  AWACs  and  Cruiser  both  said 
Ignore.  The  Cruiser  got  his  or  her  recommendation  in  first  (at  153 
seconds) ,  well  ahead  of  the  other  stations  which  came  in  roughly  20 
seconds  prior  to  the  end  of  the  trial. 

Below  this  information,  we  are  provided  with  four  tables  where  the 
communications  between  stations  are  quantified.  To  understand  the 
information  provided  in  these  tables  we  must  first  describe  the 
meaning  attached  to  the  labels  on  the  rows.  The  first  four  of 
these  will  be  self-evident,  but  the  last  5  require  some 
explanation. 

The  first  row  is  labeled  "Query,"  and  the  number  in  this  cell  tells 
how  many  times  the  person  being  reported  on  queried  the  person 
referred  to  by  the  number  (where  1  is  the  Carrier,  2  is  the  CAD,  3 
is  the  AWACs  and  4  is  the  Cruiser) .  This  table  shows  that  the 
Carrier  did  not  "Query"  anyone  during  this  trial,  nor  did  the  CAD 
or  the  Cruiser.  In  fact,  the  only  "Query"  sent  during  this  trial 
was  from  the  AWACs  who  sent  this  to  "2,"  that  is,  the  CAD. 

The  second  row  is  labeled  "Receive"  and  this  number  tells  how  many 
different  queries,  transmissions  or  messages  the  person  being 
described  received  during  the  trial.  Thus,  in  Trial  18,  the 
Carrier  received  9  messages,  3  from  the  CAD  (i.e..  Person  2),  5 
from  the  AWACs  (i.e..  Person  3),  and  1  from  the  Cruiser  (i.e.. 
Person  4) .  During  the  same  trial,  the  CAD  received  4  messages,  3 
of  which  came  from  the  Carrier,  and  1  of  which  came  from  the  AWACs. 

The  third  row  provides  the  number  of  transmissions  that  the  person 
being  described  sent  to  various  other  team  members.  Thus,  in  Trial 
18,  the  Carrier  transmitted  three  times,  one  to  each  of  the  other 
team  members.  The  CAD  transmitted  4  pieces  of  information,  3  to 
the  Carrier  and  1  to  the  AWACs. 

The  fourth  row  gives  the  number  of  text  messages  sent  between 
players.  Thus,  in  Trial  18,  the  Carrier  sent  7  text  messages,  2  to 
CAD  and  AWACs  and  3  to  Cruiser.  Moving  over  to  the  AWACs  we  see 
that  he  sent  four  messages,  all  of  which  went  to  the  Carrier. 

To  understand  the  meaning  attached  to  the  remaining  five  rows,  we 
must  first  depict  the  stages  associated  with  a  successful  instance 
of  communication  between  team  members.  Exhibit  26  depicts  the 
behaviors  that  are  required  to  have  a  question  asked  and  then 
answered  in  this  simulation.  In  the  sequence  depicted  in  Exhibit 
26,  the  AWACs  wants  to  find  out  the  Speed  of  the  target  from  the 
CAD  unit.  The  first  step  (a)  is  to  send  a  query  from  AWACs  to  CAD. 
In  the  second  step,  (b)  this  query  must  be  received  by  CAD.  In  the 
third  step,  (c) ,  the  CAD  must  transmit  the  requested  data  on  Speed 
to  the  AWACs.  Finally,  in  the  fourth  step  (d) ,  the  AWACs  must  then 
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receive  this  transmission  from  the  CAD.  This  four  step  process 
thus  completes  the  communication,  and  AWACs  now  knows  the  Speed  of 
the  target. 


Insert  Exhibit  26  here 


TIDE^  combines  many  of  the  behaviors  reflected  in  this  sequence 
into  objective  measures  of  team  process.  Returning  back  to  Exhibit 
25,  for  example,  the  fifth  row  refers  to  the  number  of  "Slights." 
A  "Slight,"  in  terms  of  Exhibit  26  occurs  when  there  is  a  step  (a) 
but  no  step  (b) .  For  example,  AWACs  is  slighted  if  he  or  she  sends 
a  query  to  CAD  and  CAD  never  bothers  to  look  at  it.  There  were  no 
"Slights"  in  Trial  18,  but  if  one  looks  at  Trial  19,  one  sees  that 
the  AWACs  was  slighted  twice,  once  by  the  CAD  and  once  by  the 
Cruiser. 

Row  six  in  the  table  displayed  in  Exhibit  25  reports  the  number  of 
"Unresponsives. "  In  terms  of  Exhibit  26,  an  "Unresponsive" 
behavior  occurs  when  there  is  a  step  (a)  and  (b) ,  but  no  step  (c) . 
For  example,  the  CAD  is  unresponsive  if  he  or  she  receives  a  query 
from  the  AWACs  but  then  never  bothers  to  send  the  AWACs  the 
information  requested.  In  Trial  19  there  were  a  couple  of 
instances  of  unresponsive  behavior.  On  one  occasion,  the  AWACs  was 
unresponsive  to  the  Carrier,  and  on  a  different  occasion,  the  CAD 
was  unresponsive  to  the  AWACs. 

Row  seven  of  the  table  displayed  in  Exhibit  25  reports  the  number 
of  "Forgets."  In  terms  of  Exhibit  26,  a  "Forget"  occurs  when  there 
is  a  step  (a) ,  (b) ,  and  (c) ,  but  no  step  (d) .  For  example,  the  CAD 
would  register  a  "Forget"  if  he  or  she  asked  for  Speed  from  the 
AWACs,  and  then  the  AWACs  sent  Speed  to  him  or  her,  but  the  CAD 
never  bothered  to  receive  it.  As  is  apparent  in  Exhibit  25.  There 
were  no  "Forgets"  in  either  Trial  18  or  19. 

If  the  four  step  sequence  is  completed  successfully,  this  is 
referred  to  as  a  "Learn,"  and  the  number  of  "Learns"  that  take 
place  in  the  trial  is  recorded  in  the  seventh  row  of  the  table 
shown  in  Exhibit  25.  A  "Learn"  means  that  the  person  involved  asked 
for  and  received  the  information  that  he  or  she  requested.  There 
were  no  actual  "Learns"  in  Trials  18  and  19.  It  is  worth  noting 
that  this  is  not  atypical  near  the  end  of  the  trial.  We  often  find 
that  with  experience  and  increased  coordination,  the  teams  make 
less  use  of  this  as  a  means  of  exchange  and  frequently  use 
"Lectures"  (described  below)  or  text  messages  in  the  place  of  the 
less  efficient,  four  step  "Learn-ing"  process. 

In  the  eighth  row,  we  also  see  the  term  "Lecture."  In  terms  of 
Exhibit  26,  a  "Lecture"  means  that  there  was  no  Step  (a)  or  (b)  — 
just  steps  (c)  and  (d)  .  In  other  words,  the  AWACs  might  have  never 
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requested  Speed  from  the  CAD,  however,  the  CAD  transmitted  this 
information  to  the  AWACs  anyway,  and  the  AWACs  received  it.  Well- 
coordinated  teams  often  use  "Lectures”  (for  example,  the  AWACs 
might  tell  the  CAD  in  a  text  message  to  'Send  me  speed  every  time') 
as  a  means  of  moving  information  around  quickly  and  efficiently. 
It  is  critical  tc  note  that  the  number  in  the  table  refers  to  the 
number  of  times  the  person  being  described  "Lectured"  others.  It 
does  not  refer  to  the  number  of  times  he  or  she  was  "Lectured  to." 
In  Trial  18  we  see  that  the  Carrier  gave  three  "Lectures,"  one  to 
each  member  of  the  team.  The  CAD  also  gave  3  "Lectures,"  but  all 
three  of  the  lectures  were  directed  at  the  Carrier. 

Finally,  the  last  row  of  the  Table  shown  in  Exhibit  25  is  labeled 
"Summary."  This  portion  of  the  table  documents  the  attributes  that 
the  person  knew  at  the  time  he  or  she  rendered  a  judgement.  As 
such,  it  is  literally  a  snapshot  of  what  this  person's  summary  box 
looked  like  just  prior  to  the  decision.  Thus,  we  can  see  that  at 
the  end  of  Trial  18  that  the  Carrier  had  information  on  seven 
attributes:  IFF,  Speed,  Angle,  Altitude,  Size,  Direction,  and 
Corridor  Status.  At  the  end  of  Trial  19,  the  Carrier  only  had 
information  on  six  attributes,  all  of  those  that  he  or  she  had  in 
Trial  18,  minus  Direction. 

Along  with  trial  by  trial  results,  the  xxxyyzzz.SUM  program 
provides  a  summary  table,  shown  at  the  bottom  of  Exhibit  25,  which 
totals  up  the  results  associated  with  outcomes  and  processes  across 
the  whole  experiment.  Thus,  we  see  that  across  the  19  trials,  this 
team  had  7  hits,  10  near  misses,  and  2  misses.  We  can  see  that 
across  the  whole  experiment , the  Carrier  queried  other  team  members 
42  times,  and  that  these  were  relatively  evenly  distributed  (14, 
13,  and  15  to  CAD,  AWACs  and  Cruiser  respectively).  In  terms  of 
"Receiving"  we  can  see  from  the  next  row  that  the  CAD,  received  73 
messages,  the  bulk  of  which  (52)  came  from  the  Carrier.  In  the 
next  row  we  can  see  that  the  Cruiser  sent  14  transmissions,  most  of 
which  were  sent  to  the  Carrier  (11) .  These  quick,  "eyeball" 
analyses  of  the  sessions  can  be  made  for  all  the  rows  contained  in 
the  tables.  This  type  of  quick-read  analysis  is  the  purpose  of 
xxxyyzzz.SUM.  All  the  information  presented  here  (and  much  more) 
is  written,  in  a  different  format  into  xxxyyzzz.SPS  where  more  fine 
grained  data-analytic  techniques  can  be  brought  to  bear.  The  data 
analytic  file,  xxxyyzzz.SPS,  will  be  discussed  later. 

xxxwzzz.MSG:  Flow  and  Content  of  Text  Messages.  A  second 
type  of  output from  TIDE^  provides  an  avenue for  examining  the 
nature  and  content  of  the  text  message  flow  between  group  members. 
When  team  members  are  allowed  to  exchange  text  messages,  a  great 
deal  of  information  that  might  otherwise  have  traveled  through  (and 
hence  be  captured  by  xxxyyzzz.SUM  or  xxxyyzzz.SPS)  the  query, 
transmit  and  receive  functions  are  instead  sent  through  the  text 
function.  If  this  happens  a  great  deal,  then  the  information 
provided  in  the  Summary  tables  of  xxxyyzzz.SUM  can  be  somewhat 


TIDE^ 

58 


misleading. 

The  reason  for  this  is  that  information  on  target  attributes  sent 
through  the  "Text  message"  function  will  not  be  picked  up  in  the 
summary  boxes  associated  with  xxxyyzzz.SUH.  Thus,  if  the  Carrier 
asks  AWACs  for  Speed  and  then  the  AWACs  responds  via  a  text  message 
(saying  verbally  that  Speed  is  "723  mph"  or  "speed  is  very  fast"  or 
"speed  —  bad"  this  text  message  is  not  recognized  as  a 
transmission.  Therefore,  xxxyyzzz.SUH  will  not  indicate  that  the 
carrier  knew  Speed,  when  in  fact  he  or  she  might  have  either  known 
it  precisely  or  had  a  general  idea  of  its  degree  of  threat  on  this 
attribute.  The  xxxyyzzz.SUH  file  might  also  record  this  as 
"unresponsive"  on  AWACs'  part  for  lack  of  an  explicit  transmission 
on  Speed,  when  in  fact  AWACs  did  fulfill  the  Carrier's  request. 

Thus,  one  must  either  turn  off  the  text  message  option  in  TIDE^,  or 
be  ready  to  content  analyze  text  messages  that  are  sent  via  this 
mode.  Sample  output  from  xxxyyzzz.HSG  is  shown  in  Exhibit  27. 


Insert  Exhibit  27  about  here 


The  H  merely  indicates  that  a  message  was  documented.  The  first 
number  to  the  right  of  this  indicates  the  trial  during  which  the 
message  was  sent.  Thus,  from  Exhibit  27  we  see  that  there  were  24 
total  messages,  4  of  which  came  in  the  first  trial,  0  during  the 
second,  1  during  the  third,  and  so  on.  After  the  Trial  number  are 
two  numbers  that  specify  where  the  text  originated  and  where  it  was 
sent.  Thus,  the  first  message  went  from  Carrier  to  CAD,  the  second 
message  went  from  AWAC  to  the  Carrier,  the  third  message  went  from 
Cruiser  to  the  AWAC,  and  so  on.  The  nvimber  to  the  right  of  this 
tells  how  much  time  was  remaining  in  the  trial  when  the  message  was 
sent.  Thus,  the  first  message  occurred  with  140  seconds  left,  the 
second  message  occurred  with  139  seconds  left,  the  third  message 
was  sent  with  130  seconds  left,  and  so  on.  Finally,  the  text 
string  printed  at  the  end  reiterates  the  sender's  name,  and 
provides  the  full  text  message. 

One  means  for  content  analyzing  these  messages  is  provided  below. 
This  is  not  the  only  way,  but  it  is  one  method  that  we  find  useful. 
In  this  method,  each  message  is  coded  using  the  decision  tree  shown 
in  Exhibit  28. 


Insert  Exhibit  28  here 


As  an  overview,  the  researcher  using  this  method  of  content 
analysis  needs  to  make  several  determinations  (i.e.,  answer  several 
questions)  regarding  each  text  message.  The  first  determination  to 
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be  made  in  coding  text  messages  with  this  decision  tree  deals  with 
whether  the  message  is  "task- related  OR  socio-emotional”  in  nature. 
If  it  is  socio-emotional,  the  message  is  coded  as  1.  If  the 
message  is  judged  to  be  task  oriented,  a  determination  is  then  made 
as  to  whether  the  person  was  "seeking  OR  providing"  task-related 
information.  After  this,  one  then  asks  whether  the  message  dealt 
with  the  "specific  target  at  hand  OR  generic  roles/rules"  type  of 
information.  If  the  message  deals  with  rules/roles  then  it  is 
coded  2  if  it  was  seeking  information  and  coded  3  if  it  was 
providing  information. 

If  the  message  dealt  with  information  on  a  specific  target,  then 
one  asks  whether  the  information  was  "transmittable  OR  not 
transmittable" .  In  this  context,  "transmittable"  simply  means 
whether  this  specific  text  message  could  have  been  handled  via 
either  the  query  or  transmit  function.  For  example,  the  text 
message  "what  is  the  speed  of  this  one,"  might  be  sent  by  someone 
seeking  information  on  the  target.  This  question  could  have  been 
handled  with  a  query,  and  was  t'^erefore  "transmittable." 
Information-seeking  requests  that  are  transmittable  are  coded  4. 
If  someone  answered  this  by  sending  the  text  message  "speed  is  725 
mph,"  this  too  was  transmittable.  Information-providing  text 
messages  that  were  transmittable  are  coded  6.  In  general, 
transmittable  target  information  is  distinguished  by  the  fact  that 
it  deals  with  raw  data,  and  therefore  could  be  handled  with  the 
query  and  transmission  functions. 

On  the  other  hand,  text  messages  could  deal  with  characteristics  of 
the  target  that  are  non-transmittable,  in  that  they  request  an 
interpretation  concerning  the  raw  data,  rather  than  a  simple  relay 
of  the  raw  data.  So  for  example,  the  information-seeking  text 
message  "Is  this  one  threatening  on  Speed?"  and  the  corresponding 
information-providing  text  message,  "This  one  is  very  threatening 
on  Speed"  represents  "non-transmittable"  target  specific 
information.  Information-seeking  text  messages  that  are  non- 
transmittable  are  coded  5.  Information-providing  text  messages 
that  are  non-transmittable  are  coded  7. 

Thus,  in  summary,  a  message  is  coded  1  if  it  is  non-task  related. 
Codes  2  and  3  are  reserved  for  text  messages  that  are  either 
seeking  or  providing  information  on  generic  rules/ roles.  Codes  4 
through  7  are  reserved  for  text  messages  that  either  seek  or 
provide  information  on  the  specific  target  being  evaluated  at  that 
time.  Codes  4  and  6  are  for  transmittable  type  exchanges,  whereas 
5  and  7  are  for  non-transmittable  type  exchanges. 

In  some  cases  it  might  be  useful  to  extend  the  coding  of  4  through 
7  one  more  step.  Specifically,  it  might  be  useful  to  code  the 
number  of  the  attribute  on  which  information  was  exchanged.  So 
for  example,  a  message  coded  6,  might  be  extended  and  coded  6-1  if 
it  dealt  with  Speed,  6-2  if  it  dealt  with  Altitude,  6-3  if  it  dealt 
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with  Size,  an  so  on.  Extending  the  coding  in  this  manner  will 
allow  the  researcher  to  accurately  augment  the  summary  information 
provide  in  the  xxxyyzzz.SUM  output  file.  That  is,  the  summary 
indicates  what  the  person  learned  about  the  target  through  the 
Measure,  Query  and  Transmission  functions,  and  extended  text 
message  coding  indicates  what  the  person  knew  about  the  target 
through  text  messages.  Since  these  are  all  the  means  of  collecting 
information  on  the  target,  this  provides  a  complete  picture  of  what 
information  the  person  had  at  the  end  of  the  trial. 

Exhibit  29  shows  how  this  coding  scheme  could  be  applied  to  ten 
different  messages.  The  purpose  of  this  explanation  is  not  to 
advocate  the  particular  coding  scheme.  Clearly,  many  other  coding 
schemes  could  be  developed  for  many  purposes.  Rather,  our  purpose 
was  to  show  the  richness  of  the  text  data  and  the  fact  that  these 


data  can  then  be  coded  into  variables  that  have  some  theoretical 
relevance.  How  this  coding  is  done  depends  on  the  pairticular 
investigation . 


Insert  Exhibit  29  here 


xxxwzzz.SPS:  Data  Analysis  Output  File.  The  third  and  final 
output  file  from  TIDE^  is  the  data  file  that  is  prepared  to  be 
processed  using  SPSS.  This  file  has  a  generic  form  so  that  there 
are  five  lines  per  trial.  The  first  line  provides  data  on  the 
target.  The  remaining  four  lines  provide  data  for  each  subject, 
(i.e..  Carrier,  CAD,  AWACs  and  Cruiser).  The  last  four  lines  are 
537  characters  long,  and  include  almost  everything  that  the  person 
did  in  the  trial,  and  when  he  or  she  did  it. 

Thus,  there  are  five  lines  of  data  for  each  trial.  Since  there  are 
almost  always  multiple  trials  in  experiments,  for  each  experiment, 
there  are  usually  x  lines  of  data  where  x  equals  the  niamber  of 
trials  times  five.  So  for  example,  a  team  with  20  trials  will  have 
a  data  set  that  is  100  lines  long  where  each  line  has  537 
characters . 

In  addition,  since  there  are  almost  always  multiple  groups  in  an 
experiment,  there  are  typically  y  lines  of  data  for  the  entire 
experiment,  where  y  equals  the  number  of  groups  times  the  number  of 
trials  times  five.  Thus,  a  study  where  40  groups  engage  in  20 
trials  generates  a  data  file  that  is  4,000  lines  long,  with  each 
line  having  537  characters. 

Any  single  experimenter  will  probably  be  interested  in  a  only 
portion  of  the  variables  captured  in  the  537  character  line.  TIDE^ 
was  developed  to  be  as  flexible  as  possible,  however.  Thus,  this 
data  file  creation  program  errs  on  the  side  of  over-inclusion 
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SO  that  it  will  fit  the  needs  of  most  users. 

Exhibit  30  shows  how  the  data  from  the  simulation  is  arrayed.  Line 
1  contains  information  on  the  groups  identification,  the  trial  and 
the  true  score,  and  the  target  attributes.  The  remaining  four 
lines  are  devoted  to  individual  players,  and  all  have  a  parallel 
structure.  In  this  structure,  the  data  is  arrayed  in  the  following 
blocks: 


Insert  Exhibit  30  here 


(a)  what  the  subject  measured  (and  when) , 

(b)  who  asked  whom  what  (and  when) , 

(c)  who  transmitted  what  to  whom  (and  when) , 

(d)  who  sent  text  messages  to  whom  (and  when) , 

(e)  who  received  queries  about  what  from  whom  (and  when) , 

(f)  who  received  what  transmissions  from  whom  (and  when), 

(g)  who  received  messages  from  who  (and  when) , 

(h)  what  the  subject  knew  about  the  target  at  three  different 
times  in  the  trial  (as  indexed  through  the  Summary  box) 

(i)  what  the  subject's  decision  was  (and  when  it  was 
registered) 

(j)  the  number  of  slights,  unresponsives,  forgets,  learns  and 
lectures  experienced  by  the  subject 

(k)  whether  the  subject  knew  both  parts  of  any  or  all  of  the 
possible  combination  rules 

Types  of  Analyses  Available  From  xxxwzzz.SPS 

There  are  many  conventional  analyses  in  the  groups  and  decision 

making  literatures  that  are  easily  run  off  the  xxxyyzzz.SPS  file. 

We  will  quickly  list  some  of  the  major  ones  below. 


Judgment  Accuracy 

One  of  the  critical  dependent  variables  in  either  individual 
decision-making  or  team  decision-making  is  the  accuracy  of 
judgments.  Accuracy  is  typically  operationalized  as  the  absolute 
difference  between  the  team/ individual  decision  and  the  true  score. 
This  can  be  calculated  by  combining  the  measures  from  line  1  with 
those  from  (i)  above.  Accuracy  is  also  sometimes  operationalized 
by  the  correlation  over  multiple  trials  between  the  decision  and 
the  true  score.  This  too  can  be  calculated  with  information  from 
line  1  and  (i)  correlated  over  multiple  trials.  Other  variables 
can  then  be  related  to  accuracy  to  test  theories  about  the  effects 
of  various  kinds  of  independent  variables  or  process  variables  on 
decision-making  accuracy. 
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Policy  Capturing  of  Raw  Data 

Another  widespread  practice  in  the  decision-making  literature  is  to 
conduct  policy-capturing  research.  In  policy  capturing  studies, 
the  influence  of  various  aspects  of  the  target  are  regressed  on 
actual  decisions  to  determine  empirically  what  information  is 
driving  decisions.  This  can  be  accomplished  off  of  xxxyyzzz.SPS  in 
a  variety  of  ways. 

First,  one  can  policy  capture  the  decisions  of  team  members  by 
regressing  their  judgments  on  raw  target  attributes.  Therefore, 
one  would  regress  the  decisions  provided  in  (i)  on  the  attribute 
information  given  in  line  1,  or  the  known  characteristics  of  the 
target  given  in  (h) . 

Second,  one  could  policy  capture  the  decision  of  the  leader  in 
terms  of  the  summary  recommendations  of  the  other  players.  Here, 
one  regresses  the  leaders  decision,  given  in  (i)  on  the  second 
line,  with  the  recommendations  of  other  team  members  given  in 
section  (i)  of  lines  3,  4  and  5. 


Process  Tracing  of  Information  Search 

Another  common  analysis  in  the  decision-making  literature  deals 
with  process  tracing.  In  process  tracing,  the  experimenter 
attempts  to  capture  the  information  seeking  processes  of 
participants,  in  terms  of  what  information  was  sought,  from  whom, 
and  at  what  time  (e.g..  Ford,  Schmitt,  Schechtman,  Hults,  & 
Doherty,  1989) .  This  can  be  accomplished  by  examining  the  timing 
of  various  information  requests  and  transitions.  Specifically, 
this  calls  for  an  analysis  of  (a) ,  (b) ,  and  (d) . 

Process  tracing  and  policy  capturing  come  together  in  studies  that 
examine  primacy  and  recency  effects.  That  is,  priming  and  recency 
studies  look  at  the  differential  impact  of  various  pieces  of 
information  on  decisions,  as  affected  by  the  order  or  timing  of 
information  acquisition.  Primacy  studies  focus  on  the  effects  of 
early  information,  and  recency  studies  focus  on  the  effects  of 
information  that  comes  in  late.  Here,  one  would  examine  the 
relationship  between  the  information  received  in  (a)  ,  (e) ,  (f)  ,  and 
(g)  with  (i). 


Socioarams  of  Communication  Flows 

In  the  groups  literature,  sociograms  are  used  to  provide  a  picture 
of  the  communication  channels  that  develop  in  groups.  That  is, 
they  attempt  to  generate  quantitative  indices  of  who  talks  to  whom 
with  what  frequency.  These  can  also  be  generated  from  xxxyyzzz.SPS 
through  an  examination  of  the  data  in  section  (b) ,  (c) ,  and  (d) . 


System  Requirements  for  TIDE^ 


TIDE^  requires  a  minimal  amount  of  hardware  and  software.  Almost 
any  IBM  compatible  system  can  run  TIDE^  and  almost  any  networking 
system  can  be  employed.  All  of  the  software  can  reside  on  a  single 
double  density  5  1/4  inch  floppy  disk. 


Hardware 

TIDE^  can  be  run  on  1  to  4  IBM  compatible  computers.  If  one  is 
using  the  One  Player  only  version  of  TIDE^  one  can  use  almost  any 
IBM  compatible  computer.  On  the  other  hand,  if  one  is  going  to  use 
a  team  version  of  TIDE^,  we  strongly  recommend  that  at  least  one  of 
the  computers  in  the  four  person  configuration  have  a  386 
processor.  In  reality,  the  team  version  of  TIDE^  actually  resides 
on  only  one  computer  in  the  dedicated  network,  which  acts  as  a 
server  to  the  other  computers.  The  team  version  of  the  program 
places  a  high  demand  on  the  server,  and  lesser  processors  will 
react  too  slowly  when  participants  are  engaged  in  the  simulation. 

This  slowness  in  response  is  of _ such  a  magnitude,  that _ 

significantly  influences  participants  behaviors  and  attitudes.  The 
other  machines  can  have  a  286  processor  with  no  significant  loss  of 
access  time. 


Software 

There  are  two  sets  of  required  software  for  running  TIDE^.  The 
first  set  is  generic  software  that  deals  with  the  basic  operating 
environment  and  the  network.  In  terms  of  the  basic  operating 
environment,  TIDE^  requires  DOS  4.01  or  higher.  In  terms  of 
networking  software,  almost  any  microcomputing  network  software 
will  work,  although  LANTASTIC  was  the  specific  software  used  in 
developing  the  program. 

The  second  set  of  required  software  is  TIDE^  specific.  TIDE^  is 
basically  a  set  of  programs  that  generate  the  simulation  and 
captures  the  data.  There  are  10  files  which  include: 

(a)  TERM.INI  —  This  identifies  each  computer  terminal  with  a 
role  in  the  simulation  (i.e..  Carrier,  CAD,  etc.). 

(b)  TEAM??. INI  —  This  file  contains  the  targets  created  in 
the  "session  to  create  or  maintain  targets"  part  of  TEAMSET 
(see  Exhibit  13) .  The  question  marks  represent  the  number  of 
the  session  being  created  and  saved.  Thus,  in  an  experiment 
that  has  participants  return  for  three  sessions,  the  three 
sets  of  targets  they  respond  to  might  be  labeled  TEAM01.INI, 
TEAM02.INI,  and  TEAM03.INI. 
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(c)  TEAHDEMO.EXE  —  This  program  constitutes  the  simulation 
itself.  In  the  default  version  of  the  simulation,  typing  in 
TEAMDEMO  and  then  hitting  return  initiates  the  simulation. 

(d)  TEAMDEMO. WGT  —  This  program  contains  the  basic  parameters 
for  TEAMDEMO.EXE.  These  are  set  in  the  "modify  weights  and 
values"  part  of  TEAMSET  (see  Exhibit  16a  and  16b) .  In  the 
default  version  of  TIDE^  the  specific  file  labeled 
TEAMDEMO. WGT  contains  the  parameters  associated  with  the 
default  version  of  the  simulation.  If  you  wish  to  generate  a 
different  set  of  parameters  you  can  label  this  new  set 
anything  you  would  like,  so  long  as  you  conform  to  the  .WGT 
suffix.  For  example,  you  could  label  the  first  variation  of 
the  default  as  "VARIANTl.WGT." 

(e)  TEAMSET.EXE  —  This  program  is  used  to  either  "create  and 
maintain  targets"  and  "modify  weights  and  values."  In  other 
words,  this  is  the  file  to  execute  if  one  wishes  to  create  a 
TEAM??. INI  file  or  a  ????????. WGT  file. 

(f)  SETCLCK.BAT  —  This  BAT  file  synchronizes  the  computer 
clocks  between  trials  to  insure  accurate  recording  of  time  in 
the  output  file.  Without  this  file,  clocks  drift  apart  over 
time,  that  is,  one  computer's  clock  may  read  55  seconds  left, 
while  another's  might  read  65  seconds  left.  This  creates 
significant  problems  for  both  the  experimenter  (in  sorting 
files)  and  the  participants  (in  coordinating  their  actions) . 

(g)  RENIX>G2  —  The  immediate  output  of  the  simulation  is  four 
raw  data  files.  These  raw  data  files  are  labeled  TEAM1.LOG, 
TEAM2.IiOG,  TEAM3.LOG  and  TEAM4.LOG  where  the  number  refers  to 
the  position  (i.e.,  1  for  Carrier,  2  for  CAD,  etc).  RENL0G2 
merges  these  into  a  single  file  organized  by  position.  When 
finished,  RENL0G2  automatically  initiates  TEAMSORT.EXE,  which 
is  discussed  next. 

(h)  TEAMSORT.EXE  ~  TEAMSORT.EXE  takes  the  files  merged  by 
RENL0G2  and  then  sorts  them  by  game  and  time  remaining  within 
the  game.  When  TEAMSORT.EXE  is  finished,  a  new  file  called 
xxxyyzzz.es  is  created.  The  CS  stands  for  combined  and 
sorted,  and  the  xxx  refers  to  the  group  number,  yy  refers  to 
the  session  number,  and  zzz  refers  to  the  experiment  number. 
This  CS  file  is  then  ready  for  data-analytic  processing  by 
TEAMSTAT.EXE,  Which  is  discussed  below. 

(i)  TEAMSTAT.EXE  —  This  is  a  program  that  converts  the 
xxxyyzzz.es  file  into  xxxyyzzz.MSG,  xxxyyzzz.SUM,  and 
xxxyyzzz.SPS  files.  The  three  latter  files  are  discussed  in 
detail  in  an  earlier  section  "Output  from  TIDE^." 

(j)  T.BAT  —  This  program  creates  a  prompt  that  states  "Type 
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t  to  start  TEAMDEMO."  When  t  is  then  typed,  this  initiates 
TEAMDEMO.  The  experimenter  then  enters  ????????. WGT,  Group 
Nvunber,  Session  Number,  and  Experiment  Number,  then  hits 
return,  and  then  the  TIDE^  Logo  Screen  appears.  From  here, 
all  one  needs  to  do  is  hit  RETURN  to  start  the  simulation. 


This  is  entered  only  at  the  server  computer  ( i . e . ,  the  default 
is  the  Carrier) .  The  other  computers,  simply  require  the  "t" 
to  be  entered. 

If  the  server  goes  down  (i.e.,  the  Carrier),  the  experimenter 
needs  to  hit  "SHIFT  FI"  on  the  other  computers.  SHIFT  FI 
turns  off  the  simulation  and  returns  the  computers  to  the  C 
prompt.  At  the  server,  the  experimenter  should  type  in  "T2" 
and  then  hit  RETURN.  Here  the  experimenter  needs  to  re-enter 
the  ???????? .WGT,  Group  Number,  Session  Niimber,  and  Experiment 
Number  and  then  hit  RETURN.  This  takes  you  back  to  the  TIDE^ 
Logo  Screen.  When  the  server  is  back  to  the  Logo  Screen,  the 
experimenter  should  then  type  "T"  on  each  of  the  other 
computers  and  then  hit  RETURN.  When  all  of  the  computers  are 
at  the  TIDE^  Logo  Screen,  you  are  ready  to  re-enter  the 
simulation.  This  program  allows  you  to  enter  a  session  at  a 
specific  game.  To  do  this,  type  "G"  (note  that  this  must  be 
a  CAPITAL  G  —  a  lower  case  g  will  not  work)  and  then  hit 
RETURN.  The  program  will  prompt  you  with  "What  trial  number." 
At  this  point,  enter  the  trial  number  immediately  after  the 
trial  number  where  the  simulation  crashed  and  then  hit  return. 
All  four  computers  will  re-enter  the  simulation  at  the 
specified  trial.  Unfortunately,  the  data  from  the  trial  where 
the  computer  crashed  will  probably  not  be  complete  (because 
the  trial  was  cut  short  by  the  crash) .  This  should  be  recoded 
as  "missing  data"  when  analyzing  xxxyyzzz.SPS. 

If  one  of  the  outlying  position  crashes,  the  procedure  is  much 
simpler.  Just  type  "T"  and  then  hit  RETURN.  The  person  at 
this  position  will  be  taken  back  to  the  TIDE^  Logo  Screen. 
The  person  will  remain  at  this  screen,  until  the  current  trial 
is  finished.  When  the  next  trial  starts,  the  person  on  the 
crashed  computer  will  then  re-enter  at  the  same  point  where 
his  or  her  teammates  are.  Again,  the  trial  where  the  program 
crashed  will  have  to  be  treated  as  "missing  data"  for  this  one 
subject  (not  the  whole  team) . 

Access  to  Software 

The  software  for  TIDE^  was  written  by  Anders  Johanson  of  the 
Applications  Services  at  Michigan  State  University  according  to  the 
requirements  generated  by  the  authors.  Version  1.0  of  TIDE^  is  as 
described  in  this  report.  Copies  of  the  disk  containing  the  TIDE^ 
software  as  described  here  are  available  for  a  small  fee  from  the 
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authors  (this  excludes  DOS  and  the  network  software) .  At  the  tine 
of  this  printing  the  fee  was  $25.00  to  cover  the  costs  of  the 
report,  disk,  shipping,  and  handling.  This  fee  can  be  waived  in 
some  instances. 

References  to  this  task  in  future  work  should  cite  this  report. 

Finally,  we  cannot  take  responsibility  for  the  use  of  the  task  by 
others  or  guarantee  the  programs  performance  on  other  systems. 
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Exhibit  lb.  Illustative  information  Distribution  and  Communication 
Structure  in  a  Hierarchical  Decision  Making  Team  with  Distributed 
Expertise . 


Key 

,  s  Cues  (Units  of  Information) 

,B,C  &  D  s  Persons  (Team  Members) 
s  Direct  Links  to  Cues 
«  Interpersonal  Communication  Paths 


+++++++ 
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Exhibit  Ic.  The  Utilization  of  Information  and  Team  Member 
Recommendations  in  the  Hierarchical  Decision  Making  Team  with 
Distributed  Expertise. 


Key 

=  Decision  Based  on  a  priori  Model 
,  =  Cues  (  Units  of  Information) 

,B,C  &  D  =  Persons  (Team  Members) 

=  Recommendations  of  Subordinate  Team  Members 
^  B  Team  Leader  Decision 

*  Cue  Validities  in  a  priori  Model 
®  Cue  Utilization  by  Team  Members  in  Arriving  at 
Recommendations 

Leaders  Utilization  of  Team  Members 
Recommendations  in  Leaders  Decision 


+++++++ 


TIDE^ 

72 


Exhibit  2.  Initial  TIDE^  Scenario 
INTRODUCTION 

The  year  is  1994  and  you  are  a  part  of  a  U.S.  naval  carrier 
groups 's  command  and  control  team  stationed  in  the  Middle  East.  A 
regional  conflict  between  two  nations  in  this  area  has  recently 
broken  out,  and  your  mission  is  to  protect  seagoing  commercial 
traffic  in  the  area  from  accidental  or  intentional  attacks.  As 
history  indicates,  this  is  a  highly  sensitive  task.  For  example, 
in  1987,  an  Iraqi  jet  accidentally  fired  two  Exocet  missiles  into 
the  Frigate  U.S.S.  Stark,  killing  37  American  servicemen  and 
crippling  the  vessel.  One  year  later,  the  U.S.S.  Cruiser  Vincennes 
accidentally  shot  down  an  Iranian  passenger  plane  killing  290 
innocent  civilians.  Any  repeat  of  mistakes  of  this  kind  will 
probably  lead  to  a  withdrawal  of  American  forces  from  the  area. 
Such  a  withdrawal  would  have  disastrous  economic  and  political 
ramifications  that  would  spread  well  beyond  this  region. 

THE  TASK  FORCE 

A  naval  carrier  battle  group  team  is  an  awesome  array  of  ships  and 
support  units.  As  shown  on  the  cover  of  this  handbook,  it  has  a 
concentric  ring  of  missile  firing  warships  which  protect  the 
aircraft  carrier  at  its  center.  The  aircraft  carrier,  in  return 
provides  an  overall  umbrella  of  air  protection  for  the  entire  task 
force.  The  carrier’s  90  planes  can  unleash  air  strikes  against 
targets  at  land,  sea  and  even  under  water.  A  carrier  group  can 
dominate  up  to  196,000  square  miles  of  Ocean.  A  standard  carrier 
group  consists  of  six  ships;  the  Carrier  itself,  two  Ticonderoga 
class  Aegis  Cruisers,  two  anti-air  Destroyers,  and  a  submarine. 

A  carrier  group  is  also  supported  by  AHACs  reconnaissance  planes 
and  a  land  based  Coastal  Air  Defense  (CAD)  unit.  Although  the 
Carrier  itself  is  equipped  with  some  air  patrol  capacities,  the 
Cruisers,  AWACs  and  CAD  units  provide  the  bulk  of  air  traffic 
patrol.  Taken  together,  the  air  patrol  groups  on  the  Carrier,  the 
Cruiser,  the  AWACs  and  the  CAD  unit  make  up  the  command  and  control 
team. 
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Exhibit  2  continued 
TEAM  MISSION 

The  team  of  which  you  are  a  part,  will  role  play  the  Commnading 
Officers  of  various  units  in  the  carrier  group.  Your  mission  is  to 
monitor  the  air  space  surrounding  the  carrier  group,  making  sure 
that  neutral  ships  are  not  attacked.  In  performing  this  role,  you 
must  make  certain  that  you  do  not  allow  loss  of  life  resulting  from 
accidental  or  intentional  attacks  on  ships  in  the  task  force.  At 
the  same  time,  it  is  also  of  paramount  importance  that  you  do  not 
inadvertently  shoot  down  friendly  military  aircraft  or  any  civilian 
aircraft.  Many  passenger  flights  move  in  and  out  of  the  region, 
and  friendly  military  aircraft  from  nations  not  involved  in  the 
conflict  also  patrol  the  area.  The  navy  can  ill-afford  any 
mistakes  of  either  the  Stark  or  Vincennes  variety. 
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Exhibit  3.  Overview  of  Roles  in  TIDE^ 

OVERVIEW  OF  ROLES 

There  are  four  roles  in  this  simulation,  one  for  each  member  of  a 
four  person  team.  The  leader  is  the  Commanding  Officer  (CO)  of  the 
Aircraft  Carrier.  The  other  team  members  include  the  CO  of  an 
AWACs  air  reconnaissance  plane;  the  CO  of  an  Aegis  Cruiser,  and  the 
CO  of  a  Coastal  Air  Defense  (CAD)  unit  located  on  the  mainland. 
The  team's  task  is  to  decide  what  response  the  carrier  group  should 
make  toward  incoming  air  targets.  Teams  base  their  decisions  on 
data  they  collect  by  measuring  characteristics  of  aircraft  that 
enter  the  group's  airspace.  These  measures  are  obtained  from 
sophisticated  radar  equipment.  Aircraft  that  are  being  tracked  on 
radar  are  called  targets.  There  are  seven  possible  choices  to  make 
for  each  incoming  target.  These  responses  are  graded  in  terms  of 
their  aggressiveness.  Each  of  these  is  described  below,  moving 
from  least  to  most  aggressive: 

(1)  IGNORE:  This  means  that  the  carrier  group  should  devote  no 
further  attention  to  the  target,  but  instead  should  focus  on  other 
possible  targets  in  the  area.  The  group  should  never  ignore  a 
target  that  might  possibly  attack,  for  obvious  reasons. 

(2)  REVIEW.  This  means  to  leave  this  target  momentarily,  so  that 
the  team  can  monitor  other  targets,  but  to  return  to  this  target 
after  a  short  period  of  time  to  update  its  status.  A  carrier 
group  can  review  a  number  of  targets,  but  not  an  infinite  number  of 
targets . 

(3)  MONITOR:  Here  the  carrier  group  should  continuously  track  the 
target  on  radar.  A  carrier  group  can  monitor  fewer  targets  than  it 
can  review,  and  thus  monitoring  diminishes  the  groups  overall 
patrol  capacity. 

(4)  WARN:  In  this  case  the  carrier  group  sends  a  message  to  the 
target  identifying  the  group  and  alerting  the  target  to  steer 
clear.  Warning  targets  that  should  be  ignored  detracts  from  the 
salience  of  legitimate  warnings.  Warning  targets  that  intend  to 
attack  is  also  bad,  since  the  warning  makes  it  easier  for  the 
attacker  to  locate  the  ship. 

(5)  READY:  This  means  to  steer  the  ship  into  a  defensive  posture 
and  to  set  defensive  weapons  on  automatic.  A  ship  in  a  readied 
position  is  rarely  vulnerable  to  attack.  This  stance  should  not  be 
taken  to  non-threatening  targets  since  weapons  set  to  automatic  can 
fire  mistakenly  at  innocent  targets  that  fly  too  close  to  the 
carrier  group.  A  ship  in  this  position  cannot  readily  use 
offensive  weapons  on  the  target. 
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Exhibit  3  continued 


(6)  LOCK-ON:  This  synchronizes  the  ship's  radar  and  attack  weapons 
so  that  the  weapons  fix  themselves  on  the  target.  A  ship  at  Lock- 
On  position  can  use  offensive  weapons  at  a  moments  notice.  A 
ship's  capacity  to  track  other  targets  is  severely  constrained  once 
it  has  Locked-On  a  single  target,  however.  Thus,  this  should  be 
reserved  for  targets  that  are  almost  certain  to  be  threatening. 

(7)  DEFEND:  Defend  is  "weapons  away."  A  defend  decision  cannot  be 
aborted  once  initiated  and  thus  must  only  be  used  when  the  group 
feels  attack  is  imminent. 
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Exhibit  4.  Target  Attributes,  Scales  and  Ranges 


Characteristics  of  Targets 

(1)  Speed:  150  to  800  mile  per  hour  (mph) 

(2)  Altitude:  5,000  to  35,000  feet 

(3)  Size:  15  to  50  meters 

(4)  Angle:  -15  degrees  (rapid  descent)  to  +15  degrees 

(rapid  ascent) 

(5)  IFF:  "Identification  Friend  or  Foe."  This  is  a 

radio  signal  that  identifies  whether  an 
aircraft  is  civilian,  para-military  or 
military,  ranging  form  .2  Mhz  (an  airliner)  to 
1.6Mhz  (a  fighter  aircraft) 

(6)  Direction:  from  +40  degrees  (passing  far  to  the  east  or 

west  of  the  carrier)  to  00  degrees  (coming 
straight  in  to  the  carrier) 

(7)  Corridor 

Status:  a  corridor  is  a  20  mile  wide  lane  open  to 

commercial  air  traffic,  and  this  is  expressed 
in  terms  of  miles  from  the  center  of  the 
corridor,  ranging  from  1  mile  (in  the  middle 
of  the  corridor)  to  50  miles  (way  outside  the 
corridor) 

(8)  Radar  Type:  the  kind  of  radar  possessed  by  the  aircraft 

ranging  from  Class  1  (weather  radar  only)  to 
Class  9  (weapons  radar) 

(9)  Range:  distance  of  the  aircraft  from  the  carrier 

ranging  anywhere  from  20  to  200  miles 
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Exhibit  5.  Determining  Levels  of  Threat  and  Forming  Judgments 
DETERMINING  THE  LEVEL  OP  THREAT 

In  general ,  the  degree  to  which  an  incoming  target  is  threatening 
depends  on  its  standing  on  the  nine  attributes.  There  are  five  simple 
rules  to  remember  in  determining  the  danger  associated  with  any  target: 

(a)  all  else  equal,  in  terms  of  IFF,  military  targets  are  more 

threatening  than  civilian  targets  (see  attribute  #5) 

(b)  SPEED  and  DIRECTION  go  together,  so  that  fast  targets  coming 

straight  in  are  most  threatening  (see  #1  and  #6  above) .  Speed 
alone  and  direction  alone  mean  nothing.  There  is  nothing  to  fear 
if  fast  targets  are  not  headed  toward  the  group.  There  is  nothing 
to  fear  from  slow  objects  headed  directly  for  the  group. 

(c)  ANGLE  and  RANGE  go  together,  so  that  descending  targets  that  are 

close  are  especially  threatening  (see  #4  and  #9  above)  .  Angle 
alone  and  range  alone  mean  nothing.  Descending  targets  that  are 
far  away,  or  close  targets  that  are  on  the  way  up  are  not 

threatening . 

(d)  ALTITUDE  and  CORRIDOR  STATUS  go  together,  so  that  low  flving 

targets  that  are  wav  outside  the  corridor  are  especially 
threatening  (see  #2  and  #7  above) .  Altitude  alone  and  corridor 
status  alone  mean  nothing.  There  is  nothing  to  fear  from  high 
flying  targets  well  outside  the  corridor  or  low  flying  targets  in 
the  middle  of  the  corridor. 

(e)  SIZE  and  RADAR  go  together,  so  that  small  objects  with  weapons 
radar  are  especially  threatening  (see  #3  and  #8  above) .  There  is 
nothing  to  fear  from  small  targets  with  weather  radar  only  or  from 
large  targets  with  weapons  radar. 

HOW  RULES  COMBINE  TO  DETERMINE  JUDGMENTS 

The  five  rules  combine  to  determine  the  overall  threat  represented  by 
the  target.  So  for  example,  if  the  team  detected  a  (a)  military 
aircraft  that  is  (b)  flying  in  straight  and  fast,  (c)  was  close  and 
descending,  (d)  was  flying  low  and  way  outside  the  corridor,  and  (e)  was 
small  and  had  weapons  radar;  the  ship  is  being  attacked  and  should 
DEFEND. 

If  the  team  detected  (a)  a  civilian  aircraft,  that  is  (b)  passing  slow 
at  an  angle,  (c)  was  far  away  and  ascending,  (d)  was  flying  high  and  in 
the  middle  of  the  corridor  and  (e)  was  large  and  had  weather  radar;  this 
is  a  passenger  plane  that  should  be  IGNORED. 
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Exhibit  5  continued 


Intermediate  responses  like  MONITOR,  WARN,  or  READY  are  to  be  used  when 
the  target  is  threatening  according  to  some  of  the  rules  but  not  all. 
For  example,  a  military  aircraft  that  is  close  and  descending  (see  rule 
c) ,  small  and  with  weapons  radar  (see  rule  e) ,  but  is  traveling  slowly 
at  an  angle  to  the  group  (see  rule  b) ,  and  is  high  and  in  the  middle  of 
the  corridor  (see  rule  d)  might  need  to  be  WARNED.  It  should  not  be 
IGNORED,  but  neither  should  it  be  shot  down. 
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Exhibit  6.  Converting  True  Score  Criterion  Values  to  Correct  Response 
Categories 


00  -  02 
03  -  05 
06  -  08 
09  “  11 
12  -  14 
15  -  17 
18  -  20 
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Exhibit  7.  The  Carrier's  Specific  Role 

Role  of  Leader  ^Carrier ^ .  The  Carrier  is  the  leader  who  makes  the 
team's  final  decision.  The  carrier  can  only  measure  and  interpret  three 
things:  (1)  Speed,  (2)  Angle,  (3)  Corridor  Status.  The  range  of  values 
and  degree  of  threat  associated  with  each  are  shown  below. 


Non-Threatening 

Degree  of  Threat 

Somewhat  Threatening 

Verv  Threatening 

Speed 

100  -  275mph 

325  -  500mph 

600  -  800mph 

\ngle 

+15  to  +8  dgs 

+3  to  -3  dgs 

-8  to  -15  dgs 

Corridor 

0  to  8  mi 

12  to  18  mi 

22  to  30  mi 

Status 

rhe  leader  is  unique  in  knowing  what  the  other  units  are  experts  in, 
tiowever.  The  area  of  others'  expertise  is  listed  below: 

im  Mbr  /  Speed  Altit  Size  Ancle  IFF  Direct  Corr.St.  Radar  Range 


» 

kCs 

iiser 


X 

X 


X 

X 


X 

X 


X 

X 


X 

X 


Summary  of  How  to  Determine  Threat  Levels 

all  else  equal,  in  terms  of  IFF,  military  targets  are  more  threatening 
n  civilian  targets  (see  attribute  #5) 

SPEED  and  DIRECTION  go  together,  so  that  fast  targets  coming  straight 
are  most  threatening  (see  #1— #6  above) .  Speed  alone  and  direction 
ne  mean  nothing.  There  is  nothing  to  fear  if  fast  targets  are  not 
ded  toward  the  team.  There  is  nothing  to  fear  from  objects  headed 
ectly  for  the  team  that  are  moving  slowly. 

ANGLE  and  RANGE  go  together,  so  that  descending  targets  that  are  close 
especially  threatening  (see  #4 — #9)  above.  Angle  alone  and  range 
ne  mean  nothing.  Descending  targets  that  are  far  away,  or  close 
gets  that  are  on  the  way  up  are  not  threatening. 

ALTITUDE  and  CORRIDOR  STATUS  go  together,  so  that  low  flving  targets 
t  are  wav  outside  the  corridor  are  especially  threatening  (see  #2 — #7 
ve) .  Altitude  alone  and  corridor  status  alone  mean  nothing.  There  is 
hing  to  fear  from  high  flying  targets  well  outside  the  corridor  or  low 
ing  targets  in  the  middle  of  the  corridor.  *** 
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Exhibit  7  continued 


(e)  SIZE  and  RADAR  go  together,  so  that  small  objects  vith  weapons  radar 
are  especially  threatening  (see  #3— #8  above) .  There  is  nothing  to  fear 
from  small  targets  with  weather  radar  only  or  from  large  targets  with 
weapons  radar. 


***  Carrier  must  memorize  this  rulel ! 
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libit  8.  The  CAD's  Specific  Role 

ir  Specific  Role 

Le  of  Land  Platform  fCAD).  The  Coastal  Air  Defense  (CAD)  unit  is  a 
icialist  in  the  measurement  and  interpretation  of  five  target 
:ributes:  (1)  speed,  (2)  altitude,  (3)  size,  (4)  angle,  and  (5)  IFF. 


The  range  of  values  and  degree  of  threat  associated  with  each  are 
)wn  below. 


Non-Threatening 

Degree  of  Threat 

Somewhat  Threatening 

Verv  Threatening 

i&d 

100  -  275mph 

325  -  500mph 

600  -  800mph 

:itude 

35, 000-27, 000ft 

23, OOOft-17, 000ft 

13, OOOft-5, 000ft 

:e 

65  -  43  mtr 

37  -  23  mtr 

17  -  10  mtr 

lie 

+15  to  +8  dgs 

+3  to  -3  dgs 

-8  to  -15  dgs 

!• 

.2  to  .6Mhz 

. 9  to  1 . iMhz 

1.4  to  1.8Mhz 

Summary  of  How  to  Determine  Threat  Levels 

i  all  else  equal,  in  terms  of  IFF,  military  targets  are  more  threatening 
in  civilian  targets  (see  attribute  #5) 

'  (b)  SPEED  and  DIRECTION  go  together,  so  that  fast  targets  coming 
raight  in  are  most  threatening  (see  #1~#6  above)  .  Speed  alone  and 
rection  alone  mean  nothing.  There  is  nothing  to  fear  if  fast  targets 
j  not  headed  toward  the  teams.  There  is  nothing  to  fear  from  objects 
ided  directly  for  the  teams  that  are  moving  slowly. 

ANGLE  and  RANGE  go  together,  so  that  descending  targets  that  are 
ise  are  especially  threatening  (see  #4 — #9)  above.  Angle  alone  and 
ige  alone  mean  nothing.  Descending  targets  that  are  far  away,  or  close 
:gets  that  are  on  the  way  up  are  not  threatening. 

ALTITUDE  and  CORRIDOR  STATUS  go  together,  so  that  low  f lying  targets 
it  are  way  outside  the  corridor  are  especially  threatening  (see  #2~#7 
>ve) .  Altitude  alone  and  corridor  status  alone  mean  nothing.  There  is 
:hing  to  fear  from  high  flying  targets  well  outside  the  corridor  or  low 
'ing  targets  in  the  middle  of  the  corridor. 

SIZE  and  RADAR  go  together,  so  that  small  objects  with  weapons  radar 
!  especially  threatening  (see  #3— #8  above) .  There  is  nothing  to  fear 
>m  small  targets  with  weather  radar  only  or  from  large  targets  with 
ipons  radar. 

'  CAD  must  memorize  this  rule! 1 
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Exhibit  9.  The  AWAC's  Specific  Role 

Role  of  Air  Platform  fAWACs) .  The  AWACs  unit  is  a  specialist  in  the 
measurement  and  interpretation  of  five  target  attributes:  (1)  angle,  (2) 
IFF,  (3)  direction,  (4)  Corridor  status,  and  Radar  Type 


The  range  of  values  and  degree  of  threat  associated  with  each  are 
shown  below. 


Non-Threatening 

Degree  of  Threat 

Somewhat  Threatening 

Verv  Threatening 

Angle 

+8  to  +15  dgs 

+3  to  -3  dgs 

-8  to  -15  dgs 

IFF 

.2  to  .6Mhz 

. 9  to  1 . IMhz 

1.4  to  1.8Mhz 

Direction 

30  to  22  dgs 

18  to  12  dgs 

08  to  00  dgs 

Corridor  St 

0  to  8  mi 

12  to  18  mi 

22  to  30  mi 

Radar  Type 

Class  1  &  2 

Class  5 

Class  8  &  9 

Summary  of  How  to  Determine  Threat  Levels 

(a)  all  else  equal,  in  terms  of  IFF,  military  targets  are  more  threatening 
than  civilian  targets  (see  attribute  #5) 

(b)  SPEED  and  DIRECTION  go  together,  so  that  fast  targets  coming  straight 
in  are  most  threatening  (see  #1 — #6  above).  Speed  alone  and  direction 
alone  mean  nothing.  There  is  nothing  to  fear  if  fast  targets  are  not 
headed  toward  the  teams.  There  is  nothing  to  fear  from  objects  headed 
directly  for  the  teams  that  are  moving  slowly. 

***  (c)  ANGLE  and  RANGE  go  together,  so  that  descending  targets  that  are 
close  are  especially  threatening  (see  #4 — #9)  above.  Angle  alone  and 
range  alone  mean  nothing.  Descending  targets  that  are  far  away,  or  close 
targets  that  are  on  the  way  up  are  not  threatening. 

(d)  ALTITUDE  and  CORRIDOR  STATUS  go  together,  so  that  low  flvlng  targets 
that  are  wav  outside  the  corridor  are  especially  threatening  (see  #2 — #7 
above) .  Altitude  alone  and  corridor  status  alone  mean  nothing.  There  is 
nothing  to  fear  from  high  flying  targets  well  outside  the  corridor  or  low 
flying  targets  in  the  middle  of  the  corridor. 

(e)  SIZE  and  RADAR  go  together,  so  that  small  objects  with  weapons  radar 
are  especially  threatening  (see  #3 — #8  above).  There  is  nothing  to  fear 
from  small  targets  with  weather  radar  only  or  from  large  targets  with 
weapons  radar. 


***  AWACs  must  memorize  this  rule!! 
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Lbit  10.  The  Cruiser's  Specific  Role 

>  of  Sea  Platform  TCruiser) .  The  Aegis  Cruiser  is  a  specialist  in  the 
surement  and  interpretation  of  five  target  attributes:  (1)  Corridor 
:us,  (2)  Radar  Type,  (3)  Range,  (4)  Speed,  and  (5)  Altitude. 

range  of  values  and  degree  of  threat  associated  with  each  are  shown 
>w. 

Degree  of  Threat 


Non-Threatening 

Somewhat  Threatening 

Verv  Threatening 

:idor 

0  to  8  mi 

12  to  18  mi 

22  to  30  mi 

:us 

ir  Type 

Class  1  &  2 

Class  5 

Class  8  &  9 

re 

200  to  110  mi 

90  -60  mi 

40  to  1  mi 

id 

100  -  275mph 

325  -  500mph 

600  -  800mph 

Ltude 

27, 000-35, 000ft 

17, OOOft-23, 000ft 

5,000ft-13,000ft 

Summary  of  How  to  Determine  Threat  Levels 

all  else  equal,  in  terms  of  IFF,  military  targets  are  more  threatening 
1  civilian  targets  (see  attribute  #5) 

SPEED  and  DIRECTION  go  together,  so  that  fast  targets  coming  straight 
ire  most  threatening  (see  #1~#6  above) .  Speed  alone  and  direction 
le  mean  nothing.  There  is  nothing  to  fear  if  fast  targets  are  not 
led  toward  the  teams.  There  is  nothing  to  fear  from  objects  headed 
sctly  for  the  teams  that  are  moving  slowly. 

ANGLE  and  RANGE  go  together,  so  that  descending  targets  that  are  close 
especially  threatening  (see  #4<— #9)  above.  Angle  alone  and  range 
le  mean  nothing.  Descending  targets  that  are  far  away,  or  close 
fets  that  are  on  the  way  up  are  not  threatening. 

ALTITUDE  and  CORRIDOR  STATUS  go  together,  so  that  low  flvlng  targets 
;  are  wav  outside  the  corridor  are  especially  threatening  (see  #2~#7 
'e) .  Altitude  alone  and  corridor  status  alone  mean  nothing.  There  is 
ling  to  fear  from  high  flying  targets  well  outside  the  corridor  or  low 
ng  targets  in  the  middle  of  the  corridor. 

(e)  SIZE  and  RADAR  go  together,  so  that  small  objects  with  weapons 
are  especially  threatening  (see  #3— #8  above) .  There  is  nothing  to 
'  from  small  targets  with  weather  radar  only  or  from  large  targets  with 
ions  radar. 


Cruiser  must  memorize  this  rule!! 


Exhibit  12.  The  Feedback  Screen 
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Exhibit  13.  The  TEAMSET  Initial  Menu  Screen 


Copyright  (C)  1990  Michigan  State  University,  All  Rights  Reserved 
TEAMSET  V011791  TEAMDEMO  Modify  Weights  &  Values  or  Sessions 


W  to  modify  Weights  &  Values 
##  of  Session  to  maintain 
E  to  end  program 


Your  choice? 


Exhibit  15.  Sample  Configurations  of  Targets 
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Exhibit  14.  The  TEAMSET  Target  Creation  Screen 
Team  Decision  -  Update  TEAM99.INI  file 


[41]  Game  set  title  =  Experiment  1 


[42] 

Goals:  20 

18 

[43] 

Single (Y) ; 

N 

Game  1  of 

20  Games 

[1] 

0 

Speed 

2 

555  mph 

[2] 

0 

Altitude 

2 

7103  ftt 

[3] 

0 

Size 

2 

10  m 

[11] 

Game  Time: 

120 

[4] 

0 

Angle 

1 

-3  degg 

[5] 

2 

IFF 

2 

1.3  Mhz 

[12] 

Feedback  : 

30 

[6] 

0 

Direction 

2 

1  degg 

[7] 

0 

Corr  Status  2 

21  mi  out 

[8] 

0 

Radar 

2 

8  Class 

[9] 

0 

Range 

2 

32  mm 

1 

111 

Defend 

Your  choice? 


Enter  [##]  to  change,  G##  to  show  game  ##,  D  to  Delete  or  S  to  Stop 
Use  [10]R  to  Randomly  assign  all  9  values.  New  Value  is 
up  to  9  (0-2)  leave  blank/null  for  0-2  also  Random. 
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xhibit  16a.  The  Measures  Screen  in  TEAMSET 


Modify  tdwgtl.WGT  Weights  &  Values 


1]  #  Measures  =  9 

[2]  #  Interactions  = 

4 

[3]  # 

Judgements  = 

8 

4]  #  Outcomes  =  5 

[5]  #  Icons  = 

4 

[6]  Message  wit  time  =  1 

[7]  [8] 

[9][10] 

_  _  - 

—  — 

-  -  [11]  -  - 

-  -  _ 

_  —  _ 

0  Speed 

1  mph 

100 

300 

301 

550 

551 

800 

0  Altitude 

1  ft 

25001 

35000  15001  25000 

5000 

15000 

0  Size 

3  m 

41 

65 

21 

40 

10 

20 

0  Angle 

2  deg 

6 

15 

-5 

5 

-15 

-6 

2  IFF 

1  Mhz 

.2 

.7 

.8 

1.2 

1.3 

1.8 

0  Direction 

1  deg 

21 

30 

11 

20 

0 

10 

0  Corr  Status 

1  mi  out 

0 

10 

11 

20 

21 

30 

0  Radar 

1  Class 

1 

3 

4 

6 

7 

9 

0  Range 

4  m 

100 

200 

50 

99 

0 

49 

nteractions;  Weight [12]  1111  NxNxNxNxN[13]  16  49  38  27 


Use  [19]  to  Vifcy/Mod  Icons,  A  for  Measurest,  B  for  Coinm+ 
nter:  [##]  to  change,  C  to  Cancel  changes,  or  W  to  Write  Mods? 
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Exhibit  16b.  The  Coninunications  Screen  in  TEAMSET 


Modify  tdgwtl.WGT  Weights  &  Values 


[14] 

[15] 

[16] 

[17] 

[18] 

Carrier 

147 

No  Call 

0 

Warn 

11 

HIT 

CAD 

12345 

Ignore 

2 

Ready 

14 

NEAR  MISS 

AWACS 

45678 

Review 

5 

Lock-on 

17 

MISS 

Cruiser 

12789 

Monitor 

8 

Defend 

20 

INCIDENT 

DISASTER 

[20]  Feedback  Type  (F/D/S) :  D  [21]  D/S  #:  3 

[22]  Feedback  to;  YYYYYYYYY  YYYY  YYYY 

Type  1111222233334444  allowed  Queries/Transmits 

[23]  Query  : YYY YYYY YYYYYYYYY 

[24]  Trn  value lYYYYYYYYYYYYYYYY 

[25]  Trn  Text  ; YYYYYYYYYYYYYYYY 

[26]  Trn  Log  ;YYYY 


Use  [19]  to  View/Mod  Icons,  A  for  Measurest,  B  for  CoDm+ 
Enter:  [##]  to  change,  C  to  Cancel  changes,  or  W  to  Write  Mods? 
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Exhibit  17a-d.  Changing  Attribute  Names 


Exhibit  17a 

Snter  new  Name  or  [CR]  only  to  keep  same 
for  1  Speed  ? 


Exhibit  17b 

iinter  new  Name  or  [CR]  only  to  keep  same 
for  1  Speed  ?  Speed 

for  2  Altitude  ? 


Exhibit  17c 

iinter  new  Name  or  [CR]  only  to  keep  same 


for 

1 

Speed 

■7 

« 

Speed 

for 

2 

Altitude 

• 

Altitude 

for 

3 

Size 

O 

• 

Size 

for 

4 

Angle 

• 

Angle 

for 

5 

IFF 

• 

Ixhibit  17d 


Inter  new  Name  or 
for  1  Speed 
for  2  Altitude 
for  3  size 
for  4  Angle 
for  5  IFF 
for  6  Direction 


[CR]  only  to  keep  same 
?  Speed 
?  Altitude 
?  Size 
?  Angle 
?  Emissions 

7 


I 
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Exhibit  18a-b.  Changing  the  Attribute  Scale  Abbreviation  ■ 


Exhibit  18a  _ 

Enter  new  Measure  suffix  or  [CR]  only  to  keep  sane  • 

for  1  nph  ? 

_  I 

Exhibit  18b 

Enter  new  Measure  suffix  or  [CR]  only  to  keep  same 
for  1  mph  ?  nph 

for  2  ft?  ft 
for  3  m?  m 
for  4  deg?  deg 
for  5  Mhz? 


Khlbit  19.  Recalibrating  the  Attribute  Scale 


nter  Measure  #?  5 
3W  enter  value  for  its 

0 

Low  ,  old  =  .2  new? 


Exhibit  20.  Establishing  Access  to  Feedback 


Carrier  CAD  NNAC  Cruiser 


View  Feedback: 
Terminai 


YYYYYYYYYYYYYYYYYYYY 
11111 222223333344444 


Feedback  of  1234A1234A1234A1234A 


Carrier  can 
acceaa  carrier 
feedback 

Carrier  can 
access  CAD 
feedback 

Carrier  can 
access  AAAC 
feedback 

Carrier  can 
access  Cruiser 
feedback 

Carrier  can 
access  aii 
feedback 
simuitaneously 


Exhibit  21.  Establishing  Query  Communication  Linkages 
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From 

To 

Query  To 


-  1111222233334444 
p  2341  3412  4123 
YYYYYYYYYYYYYYYY 


Source  of  query 


Destination  of 
query 


A  nuil  set 

A  "vertical  pair* 
that  sets  up  the 
question  can 
2  query  3 

(Y  means  yes 
and  N  means  no) 


Modify  file:  tdwgtl.UCT 


Exhibit  23.  Editted  Sea  Screen 
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Exhibit  24.  The  TEAMSTAT  k..3ter  Menu 


TEAMSTAT  Master  Menu 

V061891 

Message  File 

SPSS  File 

Summary  Report  File 

Quit 

Press  the  highlighted  letter (s)  of  the  report (s) 
you  want  produced,  then  press  ENTER. 


Exhibit  25.  A  Sample  of  the  xxxyyzzz.SUM  Output  File 


C«««  II 


Query 

Receive 

Trensalt 

Message 

Slight 

Unresponsive 

Forget a 

Learns 

Lecture 

Suneary 


0 

f 

) 

7 

0 

0 

0 

0 

i 


0 

3 

1 

2 
0 
0 
0 
0 
I 


0 

s 

1 

2 
0 
• 
0 
0 
I 


irr  $pe  Ang 
Alt  Sis  Olr 
Cor 


0 

I 

I 

3 

0 

0 

0 

0 

I 


0 

4 

4 

0 

0 

0 

0 

0 

3 


0 

3 

3 

0 

0 

0 

0 

0 

3 


0 

1 

I 

0 

0 

0 

0 

0 

0 


irr  spe  Sis 
Cor  Ang  Alt 


0 

O' 

0 

0 

0 

0 

0 

0 

0 


I 

1 

2 
4 
0 
0 
0 

1 

2 


0 

3 
I 

4 
0 
0 
0 
0 
I 


I 

1 

0 

0 

0 

0 

0 

I 

0 


Ang  Cor  Spe 
Sis  Olr  IFF 
Rad 


0 

2 

I 

0 

0 

0 

0 

0 

1 


TIDE* 

100 


Tlae  Allowed  -  210 

Proper  Judgeaent  "  1 

NCAA  MISS 

Carrier 
Judgeaent 
Tine  - 

-  2 
20S 

CAO 

Judgeaent  •  2 
Tlae  -  ISS 

AWACS 

Judgeaent  -  1 
Tlae  -  112 

Cruiser 
Judgeaent 
Tlae  - 

TOTAL  2  3 

4 

TOTAL  13  4 

total  I  2  4 

TOTAL  1 

1S3 
2  3 


0 

s 

0 

2 

S 

0 

0 

0 

0 


0 

4 

0 

1 

0 

0 

0 

0 

0 


0 

0 

0 

0 

0 

0 

0 

0 

0 


Ang  Ran  Cor 
Alt  Spe  IFF 


0 

1 

0 

1 

0 

0 

0 

0 

0 


Cane  If 

Tine  Allowed  •  210 
Proper  Judgeaent  *  I  MISS 


Carrier 

CAO 

AHACS 

Cruiser 

Judgeaent 

«n  3 

Judgeaent  ** 

0 

Judgeaent  • 

2 

Judgeaent  *■ 

4 

Tlae 

• 

307 

Tine 

• 

IIR 

Tlae 

IIS 

Tlae 

m 

200 

TOTAL 

2 

3 

4 

TOTAL 

1 

3 

I 

TOTAL 

1 

2 

4 

TOTAL 

1 

2 

3 

1 

0 

1 

0 

0 

0 

0 

2 

0 

1 

0 

0 

0 

• 

s 

2 

1 

4 

3 

1 

4 

4 

0 

3 

2 

0 

Trensalt 

3 

1 

1 

1 

3 

3 

0 

1 

• 

0 

0 

0 

0 

Message 

Slight 

S 

2 

2 

1 

2 

2 

9 

2 

2 

0 

1 

1 

0 

• 

• 

0 

0 

0 

0 

3 

0 

1 

0 

0 

0 

Unresponsive 

Forgets 

1 

• 

1 

• 

0 

• 

s 

1 

0 

1 

0 

0 

0 

0 

f 

f 

• 

0 

0 

0 

0 

0 

0 

e 

0 

0 

Learns 

Lecture 

• 

2 

• 

• 

0 

1 

• 

1 

0 

3 

0 

3 

0 

0 

• 

1 

0 

0 

• 

0 

0 

0 

0 

0 

0 

0 

Suaaary 

IFF  All 

w 

IFF  Cor  Ang 

Cor 

fn 

Rad 

Ang  Ran 

IFF 

Ang  Cor 

SI 

s 

Alt 

Sis 

Dir 

Ang 

Cor  Spe  Alt 

Totals  For  All  Caaes 


MIT-  7 

NCAA  MISS-  10 

MISS- 

2 

INCIDENT-  0 

DISASTER 

-  0 

BO- 

0 

Carrier 

CAO 

AWACS 

Cruiser 

TOTAL 

2 

3 

4 

TOTAL 

1 

3 

4 

TOTAL 

1 

3 

4 

TOTAL 

1 

3 

3 

Query 

Receive 

42 

14 

13 

IS 

12 

3 

S 

4 

22 

4 

11 

S 

S 

1 

2 

3 

117 

35 

so 

32 

73 

SO 

14 

7 

74 

S3 

IS 

7 

43 

47 

7 

9 

Trensalt 

33 

11 

13 

a 

32 

34 

7 

1 

13 

7 

1 

4 

14 

11 

1 

3 

Message 

Slight 

74 

24 

24 

34 

17 

f 

S 

3 

43 

37 

4 

2 

30 

20 

4 

4 

1 

0 

0 

1 

3 

1 

3 

0 

S 

0 

2 

3 

2 

0 

0 

2 

Unresponsive 

Forgets 

21 

s 

• 

1 

7 

2 

3 

3 

4 

1 

4 

1 

3 

1 

1 

0 

0 

0 

0 

0 

1 

0 

1 

0 

1 

0 

0 

1 

1 

0 

1 

0 

Learns 

31 

t 

s 

7 

1 

0 

0 

1 

13 

S 

7 

1 

0 

0 

0 

0 

Lecture 

2S 

f 

• 

1 

IS 

IS 

0 

0 

4 

2 

0 

4 

4 

4 

0 

0 

Coordination 


=  Uncooperatie  Acts  +  Wasted  Motions 
=  Known/Inefficiencies 
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Exhibit  27.  A  Sample  of  the  xxxyyzzz.MSG  Output  File 


M  1  4  3  140M  Cruiser  Hi, dude. 

M  131  139M  AWACS  send  money 
M  124  138M  CAD  i  do  not  know 
M  112  138M  Carrier  help  whatever 

M  3  2  1  146M  CAD  the  awak  knowsw  direction  it  is  a  possible  threat 

M  441  72M  Cruiser  I  received  a  -1  angle  from  AWAC  and  -14  from  you 

M  514  167M  Carrier  i  dont  know  size 

H  6  3  1  223M  AWACS  havent  measured 
M  614  157M  Carrier  dont  know  direction 

M  6  1  3  96M  Carrier  dont  ]cnow  size 

M  614  56M  Carrier  dont  know  size 

M  7  4  2  281M  Cruiser  Do  you  know  size? 

M  7  3  1  231M  AWACS  dont  have  size 
M  743  205M  Cruiser  Do  you  know  size? 

M  7  4  1  81M  Cruiser  don't  have  IFF 

H  813  242M  Carrier  dont  know  size 
M  841  211M  Cruiser  what  did  you  want? 

M  8  1  4  141M  Carrier  dont  know  altitude 
M  834  96M  AWACS  dont  know  size 

M  842  40M  Cruiser  You  need  to  send  me  size  as  soon  as  you  get  it 

OK? 

M  941  217M  Cruiser  What  things  can  you  measure? 

M  914  179H  Carrier  speed  angle  and  corridor 
M  9  3  1  162M  AWACS  dont  know  #$%&**§!$%  altitude 
M  942  95M  Cruiser  Thank  you.  < 


Exhibit  28.  Content  Analysis  Coding  Scheme  for  xxxyyzzz.HSG 
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Task 


Seek 

Role/Rulee 

Target 


(4)  (5) 


Att  #  Att  # 


Social 

(1) 

Provide 

Role/Rulea 

Target 


/ 

V 

(6) 

1 

(7) 

1 

Att  # 

Att  # 

Task  or 
Social 


Seek  or 
Provide 


Exhibit  29.  Examples  of  Coded  Text  Messages 


1  I  dont  know  size 

2  I  received  a  -1  angle  from  AWAC  and  -14  from  you. 

3  The  speed  is  540mhp 

4  is  this  target  bad  on  speed? 

5  Can  you  send  me  size  as  soon  as  you  get  it  every  time 

6  What  is  the  IFF? 

7  What  things  can  you  measure? 

8  I  can  measure  speed  IFF  and  direction 

9  This  target  is  very  very  bad!!!! 


10  Thank  you. 
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Exhibit  30.  Format  for  xxxyyzzz.SPS  Output  File 


The  layout  of  the  fixed  format  data  analysis  output  file. 

Line/Column  Desoription  Vaules 


1  1-3 

4-5 
6-8 
9-10 
11 

2-5*  1-36 


37-126 


127-216 


217-256 


257-346 


347-436 


Group  number: 

Session  number: 

Experiment  number: 

Game  number: 

Correct  judgement  for  game: 

Measurement  data:  9  blocks  of 
4  digits  in  the  form  MTTT. 

M  is  each  of  9  attributes: 


TTT  is  time  left  in  game: 

Query  data:  18  blocks  of  5 
digits  in  the  form  WwTTT. 

W  is  who  was  queried: 
w  is  which  attribute: 

TTT  is  time  left  in  game: 

Transmission  data:  18  blocks 
of  5  digits  in  the  form  WwTTT. 

W  is  where  the  transmission  was 
sent: 

w  is  what  attribute  was  sent: 
TTT  is  time  left  in  the  game: 

Message  data:  10  blocks  of  4 
digits  in  the  form  WTTT. 

W  is  who  was  sent  the  message: 
TTT  is  time  left  in  game: 

Receive  query  data:  18  blocks 
of  5  digits  in  the  form  WwTTT. 

W  is  who  the  query  was  from: 


000-999 

00-99 

000-999 

1-99 

1-7 


l=measured 
0=not  measured 
9=can't  measure 
001-999 


1-4 

1-9 

001-999 


1-4 

1-9 

001-999 


1-4 

001-999 


1-4 


w  is  what  attribute  was  asked  for:  1-9 
TTT  is  time  left  in  game:  001-999 

Received  transmission  data:  18 
blocks  of  5  digits  in  the  from 
WwTTT. 

W  is  who  the  trans  was  from:  1-4 

w  is  what  attribute  was  sent:  1-9 

TTT  is  time  left  in  game:  001-999 


Exhibit  30  continued 
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437-476  Received  message  data:  10 

blocks  of  4  digits  in  the  form 
WTTT. 

W  is  who  sent  the  message:  1-4 

TTT  is  time  left  in  game:  001-999 

477-478  Nximber  of  time  the  summary  box 

was  accessed:  00-99 

479-490  Summary  data  second  to  last  time 
viewed  in  the  form  abcdefghiTTT. 

a  is  the  first  attribute:  l=available 

0=not  available 

b  through  i  are  in  the  same 
format: 

TTT  is  time  left  in  game:  001-999 

491-502  Summary  data  next  to  last  time 

viewed  in  the  form  abcdefghiTTT. 

(same  as  above) 

503-514  Summary  data  last  time  viewed  in 
the  form  abcdefghiTTT. 

(same  as  above) 


515-518  Judgment  data:  4  digits  in  the 
form  JTTT. 

J  is  the  judgment:  0-7 

TTT  time  left  in  game:  001-999 

519-523  Communication  summary  data  with 
station  number  2  in  the  form 
SUFLl . 

S  is  the  number  of  slights:  1-9 

U  is  the  number  of  non-responses:  1-9 

F  is  the  number  of  forgets:  1-9 

L  is  the  number  of  learns:  1-9 

1  is  the  number  of  lectures:  1-9 

524-528  Communication  summary  data  with 
station  number  3  in  the  form 
SUFLl . 

S  is  the  number  of  slights:  1-9 

U  is  the  number  of  non-responses:  1-9 

F  is  the  number  of  forgets:  1-9 

L  is  the  number  of  learns:  1-9 

1  is  the  number  of  lectures:  1-9 


Exhibit 

529 

534 
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30  continued 


-533  Conununication  summary  data  with 
station  number  4  in  the  form 
SUFLl . 

S  is  the  number  of  slights:  1-9 

U  is  the  number  of  non-responses:  1-9 

F  is  the  number  of  forgets:  1-9 

L  is  the  number  of  learns:  1-9 

1  is  the  number  of  lectures:  1-9 


-537 


form  ABCD. 


available: 


available: 


available: 


available: 


1  data: 

4  digits  in  the 

first 

interaction 

0) 

0)  o 
>t  c 

II  II 
H  O 

second 

interaction 

l=yes 

0=no 

third 

interaction 

l=yes 

0=no 

forth 

interaction 

l»*yes 

0=no 
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